2. Bedienung des Systems

Wir haben uns bemב¶ht, die Verwendung von FremdwבÀrtern zu vermeiden oder
diese mit ב£bersetzungen zu versehen. Aber gerade im Computerjargon
kommen viele aus dem Englischen ב¶bernomme Ausdrב¶cke vor, die kaum direkt
ב¶bersetzbar sind oder Einsteigern gar nicht bekannt sein kבÀnnen. Stoבƒen Sie in
diesem Handbuch auf solche Ausdrב¶cke, sehen Sie doch einfach nach, ob wir
dazu eine Begriffserlבñuterung im Anhang dieses Buchs nachgetragen haben.
Wir haben uns bemב¶ht, diese Ausdrב¶cke kursiv hervorzuheben.

2.1 Los geht's −
Installieren und Ausprobieren

Voraussetzungen

Wir gehen davon aus, daבƒ Sie vor Ihrem Atari STΓêÆComputer sitzen und neben
diesem Handbuch die mitgelieferten Disketten zur Hand haben. (Die Regi-
strierkarte, die der Lieferung beilag, haben Sie bestimmt schon ausgefב¶llt, um
in den Genuבƒ aller Updates und Erweiterungen zu Megamax Modula zu kom-
men?)

Auבƒerdem sollten Sie einige leere Disketten bereithalten, um BackupΓêÆ (Sicher-
heitsΓêÆ) und Arbeitskopien anzulegen: 4 doppelseitige Disketten fב¶r Backups;
zusבñtzlich 2 Disketten fב¶r die Zusammenstellung maבƒgeschneiderter Arbeits-
disketten. (Natב¶rlich genב¶gt auch etwas Platz auf einer Festplatte...)

Einige Worte zur Konfiguration des Rechners: Fב¶r ein komfortables Arbeiten
mit Megamax Modula ist eine freie RAMΓêÆKapazitבñt von 2 MByte und einer
Festplatte wב¶nschenswert.

Die Benutzung von Megamax Modula auf einem Atari mit nur 512 KByte RAM
ist nicht mבÀglich. Voraussetzung dafב¶r wבñre eine gegenב¶ber der mitgelieferten
stark verkleinerte Shell, die kein GEM benutzt. Eine solche Shell ist zwar
schnell erstellt, aber wir weisen lieber darauf hin, den Atari auf mindestens
1 MByte aufzurב¶sten. In den Fachzeitschriften lassen sich einfach einzubauende
Speichererweiterungen schon fב¶r ca. DM 300.ΓêÆ finden.

Die Modula−Disketten

Die Aufteilung und Anzahl der mitgelieferten Disketten variiert von Zeit zu Zeit,
so daבƒ wir Ihnen hier nur alle zumindest vorhandenen Dateien und Ordner auf-
zeigen, um Ihnen die ב£bersicht zu erleichtern. In der Regel werden die Disket-
ten zweiseitig beschrieben ΓêÆ wenn Sie sie nicht in den Computer einlesen kבÀn-
nen, wenden Sie sich bitte an Ihren Hבñndler, damit er Ihnen die Disketten auf
einseitige umkopiert, oder an Application Systems. ב£ber weitere Besonderheiten
und zusבñtzliche Dateien werden Sie in der Datei LIESMICH.TXT informiert, die
sich auf einer der Disketten befindet.

GEP ED Ordner, der den GepardΓêÆEditor enthבñlt: _

GEP ED.MOD Der Gepard−Editor (nur unter der Shell zu starten!) _

GME Ordner; enthבñlt die Dateien fב¶r den Editor "GME"

GME.MOD Der Editor

...IMP Zum GME gehבÀrende Module

GMEMENUE.RSC Die GEMΓêÆResourceΓêÆDatei fב¶r den GME

SRC Ordner mit Quelltexten. Enthבñlt vier Ordner fב¶r:

D Definitions−Texte. Achtung: Sind ggf. erst zu dekom−

primieren (siehe HINWEIS−Text auf der Diskette)

DEMO Diverse Demonstrationsprogramme

MOS Quellen zum Megamax−System, die Sie bei Bedarf

selbst modifizieren kבÀnnen (z.B. die Shell)

UTILITY Diverse Hilfsprogramme

SYS Ordner mit Modulen und anderen Systemdateien:

IMP Ordner mit den ב¶bersetzten ImplementationsΓêÆModulen

(werden beim Ausfב¶hren vieler Programme unter der
Shell benבÀtigt)

MOD Ordner mit Compiler, Linker, Make usw.

DEF Ordner mit ב¶bersetzten DefinitionsΓêÆModulen (werden

vom Compiler beim ב£bersetzen benבÀtigt):

MM2DEF.M2L Enthבñlt die unverבñnderlichen DEFΓêÆModule der MegaΓêÆ

max−Bibliothek in komprimierter Form.

MM2SHELL.DEF Ein einzelnes DEF−Modul: Es definiert die Resource−

Indices der Shell und kann sich בñndern, wenn die
GEM−Resource modifiziert wird.

MODULA.ERR Textdatei mit Fehlermeldungen fב¶r den Compiler

USER Ordner fב¶r Ihre eigenen (QuelltextΓêÆ) Dateien.

DEF Hier kommen ב¶bersetze DefinitionsΓêÆModule rein

IMP Dito fב¶r ImplementationsΓêÆModule

MOD Dito fב¶r HauptΓêÆModule

Die Quelltexte sollten auch hier im Ordner USER abgelegt
werden.

TMP Ordner, in dem die Shell interne Dateien zwischenzeitlich
ablegt (auch das Make−Programm!).

TEMPLMON.Vxx Ordner mit Maschinensprache−Monitor.

MM2SHELL.PRG Die ModulaΓêÆShell (Bedienungsoberflבñche)

MM2SHELL.RSC GEMΓêÆResourceΓêÆDatei fב¶r die Shell

MM2SHELL.RSD Zusatzdatei zur Resource−Datei

MM2SHELL.M2P ParameterΓêÆDatei fב¶r die Shell

MM2SHELL.M2B BatchΓêÆDatei ΓêÆ wird beim ShellΓêÆStart ausgefב¶hrt

MM2SHELL.HLP Textdatei mit Hilfestellungen fב¶r die ShellΓêÆBedienung

LIESMICH.TXT Diese Datei unbedingt lesen! (z.B. nach dem Shell−Start

durch einen Doppelklick in den Editor laden)

NRSC ASH.PRG Programm zum Bearbeiten von GEM−Resourcen _

NRSC.RSC Resource−Datei zum Programm

Das "Resource Construction"−Programm wird zur Erstellung von
GEMΓêÆMenues und anderen GEMΓêÆObjekten benבÀtigt. Mehr dazu finden
Sie in den Kapiteln 5 und C.2.

HD INST.PRG Hiermit kann das Modula−System bequem auf der _
Festplatte installiert werden.

DEMO enthבñlt einige Beispielprogramme, die Ihnen vielleicht den Einstieg in
Megamax Modula erleichtern. In UTILITY finden sich einige Hilfsprogramme,
die Sie compilieren sollten, um dann die erzeugten Code−Dateien auf ihre
Arbeitsdisk (Ordner SYSב¶MOD) zu kopieren. Sehen Sie sich alle diese
Dateien an, z.B., indem Sie sie in den Editor laden. Sie enthalten alle eine
Information zu Beginn des Textes.

Der Ordner MOS ist eher fב¶r fortgeschrittene Benutzer interessant: Er
enthבñlt die Quelltexte einiger Module, die Sie verבñndern kבÀnnen, um die
Konfiguration der Bibliotheken und der Entwicklungsumgebung (Shell) Ihren
eigenen Wב¶nschen anzupassen.

Besonders hilfreich ist der Ordner D. Er enthבñlt die Definitionstexte, die
auch im Kapitel B dieses Handbuchs abgedruckt sind. Aus Erfahrung
wissen wir, daבƒ man oft Funktionen nachschlagen will und es dann beim
ב¶blichen Schreibtischchaos recht unbequem ist, im Handbuch herumzu-
blבñttern. Wenn Sie genב¶gend Massenspeicher (Festplatte) haben, reicht es
nun aus, im Editor ein neues Fenster zu בÀffnen und den benבÀtigten
Definitionstext hineinzuladen. Der Gepard−Editor erlaubt es sogar, nach
exportierten Bezeichnern zu suchen und dann die entsprechende Definitions−
Textdatei anzuzeigen (mit der F6−Taste, wenn der Cursor auf dem
gesuchten Bezeichner steht!).

Installieren von Megamax Modula

Auf die Gefahr hin, daבƒ wir Sie langweilen: Haben Sie schon BackupΓêÆKopien
aller gelieferten Disketten gemacht? Die Disketten sind nicht kopiergeschב¶tzt.
Es sollte also keine Schwierigkeiten bereiten, Kopien anzufertigen und die
Originale in Sicherheit zu bringen. Vorsicht: Vor dem Kopieren sollten Sie die
Originale schreibschב¶tzen (Loch ist offen), um sie bei einer Verwechslung nicht
gleich zu lבÀschen!

Mit den Kopien in der Hand kבÀnnen Sie sich jetzt Ihre Arbeitsdisketten zusam-
menstellen. Wir beschreiben zwei verschiedene Rechner−Konfigurationen:

* Atari ST mit mindestens 1 MByte RAM, mindestens 720 KByte Diskettenplatz

* Atari ST mit mindestens 1 MByte RAM, Festplatte

Atari ST mit mindestens 1 MByte RAM, mindestens 720 KByte Diskettenplatz

Die gelieferten Disketten sind bereits sinnvoll aufgeteilt. Auf der Disk mit der
Shell befinden sich neben den fב¶r die Shell notwendigen Dateien
(MM2SHELL.M2P, MM2SHELL.M2B, MM2SHELL.RSC) auch die Module, die
resident geladen werden: der Compiler (im SYSב¶MODΓêÆOrdner) und beide
Editoren (Ordner GEP ED bzw. GME). Die andere Diskette enthבñlt dann die _
zum Arbeiten benבÀtigten Dateien, wie DefinitionsΓêÆCodes (MM2DEF.M2L) und
importierte Module (Ordner SYSב¶IMP). Ihre selbst ב¶bersetzten Dateien werden
im USERΓêÆOrdner abgelegt, worin Sie auch Ihre Quelltexte ablegen kבÀnnen.

Sie kבÀnnen also die Shell von der einen Diskette starten; ist sie fertig, kann
die andere Disk eingelegt werden, um dann eigene Programme oder die
mitgelieferten Programme in den Ordnern DEMO und UTILITY zu ב¶bersetzen
und zu starten.

Beachten Sie aber, daבƒ die ParameterΓêÆDatei der Shell auf der BootΓêÆDisk
abgelegt ist. Wenn Sie den Menב¶punkt Parameter ...speichern wבñhlen oder die
Parameter beim Verlassen der Shell speichern wollen, mב¶ssen Sie zuvor die
Boot−Disk einlegen. Es passiert zwar nichts schlimmes, wenn Sie dies nicht
befolgen, allerdings wב¶rde beim erneuten Start der Shell von der BootΓêÆDisk
wieder die alte ParameterΓêÆDatei geladen werden. Notfalls kבÀnnen Sie die Datei
auch einfach auf die BootΓêÆDisk zurב¶ckkopieren.

Ein בñhnliches DiskettenΓêÆProblem entsteht bei der Benutzung des GME. Der
Editor benבÀtigt beim Start seine ResourceΓêÆDatei GMEMENUE.RSC. Wenn Sie
nur ein Laufwerk haben, mב¶ssen Sie aufpassen, daבƒ beim Start des Editors
eine Disk mit dieser Datei im Ordner GME einliegt. Wollen Sie Texte von
anderen Disketten vom Laufwerk A: lesen, mב¶ssen Sie erst den Editor starten
(Tastendrב¶cke: ControlΓêÆP, Esc, Return, ControlΓêÆE) und erst dann die Disk
wechseln und im Editor die gewב¶nschte Datei laden.

Besser ist es dann schon, zwei Laufwerke zu verwenden − dann braucht auch
die Boot−Disk mit der Shell und ihrer Parameter−Datei nicht entfernt werden,
so daבƒ das vorher beschriebene Problem ebenfalls nicht entsteht. Allerdings
mב¶ssen dazu erst einige Parameter in der Shell und die Suchpfade geבñndert
werden.

Mב¶ssen aus Platzmangel mal die geladenen Programme (z.B. Compiler und
Editor) entfernt werden, werden sie bei erneuter Benutzung auf der gerade
eingelegten Diskette gesucht. Ggf. mב¶ssen Sie sich Editor und Compiler dazu
auf die Arbeitsdisk kopieren, damit Sie nicht jedesmal extra die Disk mit der
Shell wieder einlegen mב¶ssen.

Das Programm HD INST.PRG auf einer der Disketten wird beim Arbeiten nicht _
benבÀtigt und kann daher von dort entfernt werden, um Platz auf der Disk zu
gewinnen.

Um das ModulaΓêÆSystem nach Ihren Wב¶nschen zu konfigurieren, lesen Sie bitte
ב¶ber die Parameter von Shell, Editor und Compiler sowie ב¶ber die BatchΓêÆ
Dateien fב¶r die SuchpfadΓêÆBestimmung in Kapitel 2.2 nach.

Im Ordner MAXIDISK.4MB finden Sie eine RAM−Disk, die sogar die darin
gespeicherten Daten komprimieren kann. Sobald Sie mit der Bedienung und
Konfiguration vertraut sind, kבÀnnen Sie sich eine BootΓêÆDisk erstellen, die
automatisch die RAMΓêÆDisk einrichtet und die von Ihnen benבÀtigten Definitions-
module sowie die Fehlerdatei MODULA.ERR in die RAM−Disk kopiert. Wenn Sie
dann die Suchpfade entsprechend einstellen, kבÀnnen Sie das ב£bersetzen
erheblich beschleunigen.

Atari ST mit mindestens 1 MByte Speicher und Festplatte

Hier ist alles ganz einfach. Sie brauchen lediglich auf der Festplatte irgendwo
einen Ordner fב¶r das ModulaΓêÆSystem anzulegen ("MM2" wבñre ein schבÀner
Name) und dann alle Dateien, so wie sie auf den Disketten angeordnet sind,
1 hineinzukopieren. Auf der Festplatte sollten dazu ca. 3 / MB frei sein. Damit
2 es auch dabei keine Schwierigkeiten gibt, haben wir das Programm
HD INST.PRG vorbereitet. Es braucht nur gestartet zu werden und dann
_ sollten Sie, wie vom Programm aufgefordert, die vier Disketten nacheinander
einlegen. Dann werden einfach alle Dateien auf die Festplatte kopiert. Weitere
Konfigurationen brauchen erstmal nicht vorgenommen werden. Sie sollten
spבñter aber noch die DefinitionsΓêÆModule in der Library decomprimieren. Lesen
Sie dazu Kapitel 2.4.

Schon ist alles vorbereitet − die Shell kann nun gestartet werden. Erst, wenn
Sie die Strukturen der Ordner בñndern wollen, mב¶ssen Sie die Parameter in
der Shell und die Suchpfade im Batch (MM2SHELL.M2B) anpassen. Doch dazu
sollten Sie erstmal Kapitel 2.2 durchlesen!

Speicherplatzmangel?!

Wenn Sie nun die Shell starten, sollten nach dem Laden von Compiler
und Editor mindestens noch 200 KB (ca. 200.000 Byte) Speicher frei
sein, sonst werden sich bald Compiler, Editor oder Linker diesbezב¶glich
beschweren. Vor allem, wenn Sie ein Fan von Accessories oder AUTO−
OrdnerΓêÆProgrammen sind und Ihr Rechner nur ב¶ber 1 MB Speicher verfב¶gt,
kann es dazu kommen. Den noch freien Speicher kבÀnnen Sie ב¶ber den Menב¶-
punkt Info/Umgebungsinformationen erfahren.

Sie haben bei zu knappem Speicher keine Datenverluste zu befב¶rchten! Reicht
der Speicher im Editor nicht mehr, kann immer noch der bisher erzeugte Text
gesichert werden, bei Compiler, Linker und anderen Dienstprogrammen kann
die Operation ja sowieso wiederholt werden. Um den freien Speicher zu
vergrבÀבƒern, haben Sie verschiedene MבÀglichkeiten:

* Geben Sie die sonst noch geladenen Programme aus dem Speicher frei (das
zu startende Programm selbst braucht nicht entfernt werden). Dazu בÀffnen
Sie das Resident−Fenster (Taste R) und ziehen die angezeigten Programme
in den Abfalleimer. Dauerhaft kבÀnnen Sie auf das Laden der Programme
ganz verzichten, indem Sie die Load−Anweisungen aus dem Shell−Batch
entfernen (siehe Kapitel 2.2).

* Verwenden Sie den GepardΓêÆEditor. Er benבÀtigt und belegt (als residentes
Programm) deutlich weniger Speicher als der GME. Ersetzen Sie dann
die Anweisung LOAD GME durch LOAD GEP ED in der Batch−Datei _
MM2SHELL.M2B. Diese בänderung kann mit dem Editor durchgefב¶hrt werden.

* Verzichten Sie auf andere residente Programme, wie Accessories oder
AUTO−Ordner−Programme (z.B. Cache).

* Starten Sie den Compiler bzw. den Linker als gelinktes Programm von einer
anderen Shell aus. Diese LבÀsung ist zwar nicht so komfortabel wie mit der
MegamaxΓêÆShell, aber lבÀst dafב¶r auch die grבÀבƒten Platzprobleme. Siehe dazu
die Erlבñuterungen in den Quelltexten von LinkInit und CompInit (LINKINIT.M &
COMPINIT.M im UTILITY−Ordner).

Mehr Geschwindigkeit...

Haben Sie keine Platzprobleme, kבÀnnen Sie Ihr System auf Geschwindigkeit
trimmen. Hier einige Tips:

Wenn Sie eine Festplatte haben, verwenden Sie unbedingt TOS 1.4 (Rainbow−
TOS, enthבñlt u.A. die Zahl 1989 in der InfoΓêÆBox des Desktops) oder hבÀher. Die
בñlteren TOSΓêÆVersionen sind sehr, sehr langsam beim Speichern und Laden.
Das TOS 1.4 gibt es bei fast jedem AtariΓêÆHבñndler; oder sehen Sie mal in die
Kleinanzeigen der Computerzeitschriften.

Haben Sie TOS 1.4 (oder hבÀher), verwenden Sie das CacheΓêÆProgramm von
Atari! Es heiבƒt beispielsweise CACHE90.PRG und gehבÀrt in den AUTOΓêÆOrdner.
Gegenב¶ber den meisten anderen Caches puffert dieser nicht wahllos jeden
Sektor, sondern gezielt FAT und Verzeichnisse. Da Megamax Modula−2
intensiver als jedes andere Programm auf die Verzeichnisse zugreift, macht
sich der Atari−Cache hier besonders gut bemerkbar. Zudem: Da es im Grunde
kein Disk−Treiber ist, sondern lediglich die Puffer des GEMDOS erweitert, ist
es prinzipbedingt jedem anderen Cache ב¶berlegen.

Wie gesagt, Megamax ModulaΓêÆ2 greift hבñufig auf die Dateiverzeichnisse zu, um
Modulcodes und ΓêÆdefinitionen zu laden. Deshalb sollten die am hבñufigsten
benבÀtigten Dateien mבÀglichst schnell gefunden werden. Dazu sollten Sie die
Suchpfade entsprechend ordnen: Am Besten wבñre es, wenn sich alle Dateien
im jeweils ersten Suchpfad befבñnden.

Sie sollten die Definitionsdateien in der Bibliothek MM2DEF.M2L entpacken.
Mehr dazu im Kapitel 2.4.

ב£berhaupt genieבƒt die Bibliotheksdatei einen Sonderstatus: Beim Start des
Compilers wird sie einmal geבÀffnet, das gesamte Verzeichnis wird in den
Speicher geladen. Die darin befindlichen Dateien werden am Schnellsten
gefunden. Sie kבÀnnen Ihre eigenen Definitionsmodule auch in diese Datei
einfב¶gen (mit dem LibManager, s. Kap. 2.4).

Benutzen Sie Turbo ST oder Quick ST. Dies sind Programme, die die
GEM−Bildschirmausgaben um ein Vielfaches beschleunigen. Wir empfehlen Ihnen
Quick ST, das auch Erweiterungen wie Hyperscreen/Overscan und GDOS
unterstב¶tzt. Sie erhalten Quick ST gegen Einsendung eines Schecks ב¶ber 25
US Dollar bei folgender Adresse:

Branch Always Software

14150 N. E. 20th St. # 302

Bellevue
WA 98007

US A

Namenskonventionen

Falls Sie schon mit anderen Modula−2−Systemen gearbeitet haben, wollen wir
Sie gleich darauf hinweisen, daבƒ wir andere Endungen bei den Dateinamen
verwenden. Die Quelltexte haben alle nur einen Buchstaben als Endung, und
zwar M fב¶r HauptΓêÆ, I fב¶r ImplementationsΓêÆ und D fב¶r Definitionsmodule. Die
entsprechenden Code−Dateien haben MOD, IMP bzw. DEF als Endung. Der
Name der Code−Datei wird nicht aus dem der Quelldatei gebildet, sondern aus
den ersten acht Buchstaben des Modulnamens, der im Quelltext steht.

Wenn Sie gerne andere Endungen verwenden wollen, brauchen Sie lediglich die
Variablen im Quelltext der Shell (MM2SHELL.M) zu בñndern (suchen Sie dort
nach den z.Zt. verwendeten Endungen), ב¶bersetzen und die Shell neu zu linken
(siehe dazu Kapitel 2.6). Natב¶rlich mב¶ssen Sie auch noch die Endungen der
mitgelieferten Dateien alle בñndern, auch die in der Library (MM2DEF.M2L).

Mathe−Koprozessor (FPU, SFP 004, Atari TT)

Wבñhrend der Atari TT serienmבñבƒig ב¶ber eine FPU verfב¶gt, kבÀnnen Sie sie beim
Atari ST/STE nachrב¶sten (z.B. SFP 004 von Atari). Beim ST wird in der Regel
ein 68881, beim TT ein 68882 eingesetzt. Beide sind weitgehend identisch, so
daבƒ wir beim Prozessortyp keine Unterschiede machen brauchen.

Allerdings wird eine FPU im ST anders angesteuert als im TT. Aus Grב¶nden,
die im Kapitel ב¶ber den Compiler (Kap. 3.4, FΓêÆDirektive) weiter ausgefב¶hrt
werden, mב¶ssen Sie die Shell bzw. alle gelinkten Programme mit den dafב¶r
angepaבƒten FPUΓêÆModulen binden, um die FPU auch nutzen zu kבÀnnen. Dazu
verwenden Sie je nach Rechnertyp die Module aus den Ordnern ST FPU bzw. _
TT FPU. _

Das einfachste ist, die Module aus einem der Ordner in den IMP−Ordner zu
kopieren. Dabei werden allerdings die "normalen" Module, die keine FPU
benutzen, ב¶berschrieben. Wenn Sie schon mit der בänderung der Pfadlisten
vertraut sind, tragen Sie besser den passenden FPU−Ordner als jeweils ersten
Suchpfad bei DefaultPath und ImpPath ein. Dann werden die Dateien dieses
Ordners bevorzugt verwendet.

Linken Sie dann die Shell neu, damit Programmodule, die unter der Shell
ב¶bersetzt und per LoadtimeΓêÆLinking gestartet werden, auch gleich die FPU
mitbenutzen kבÀnnen. Wie Sie die Shell linken, erfahren Sie in Kapitel 2.6; oder
starten Sie einfach den Batch LINKSHEL.M2B.

Mit den FPUΓêÆModulen gelinkte Programme kבÀnnen Sie nicht auf Rechnern ohne
die entsprechende Hardware einsetzen! Sie werden dann eine Fehlermeldung
erhalten.

Ein erstes Programm

Um Megamax Modula richtig nutzen zu kבÀnnen, sollten Sie als nבñchstes die
Kapitel 2.2 (Shell), 2.3 (Editor) und 2.4 (Compiler) lesen. Bevor Sie grבÀבƒere
Programme schreiben, verdient auch Kapitel 3 Ihre Aufmerksamkeit. Aber viel-
leicht sind Sie im Moment einfach neugierig, ob Ihr neues Modula−System
ב¶berhaupt funktioniert? Dann tun Sie doch erstmal folgendes...

Shell starten

Bereiten Sie den Atari vor, wie
oben fב¶r Ihre RechnerΓêÆKonfiguration
beschrieben, und legen Sie ggf. die
Diskette mit MM2SHELL.PRG in
Laufwerk A ein. Starten Sie
MM2SHELL.PRG durch einen
Doppelklick. Nach einiger Zeit er-
scheint eine Arbeitsflבñche, die dem
GEMΓêÆDesktop בñhnelt:

Programm eingeben

Auf der Arbeitsflבñche finden Sie unter anderem eine Box Aktuelle Datei. Im
Namensfeld sollte hinter TEXT kein Name stehen. Um dies ggf. zu erreichen,
kבÀnnen Sie das Feld doppelt anklicken oder ControlΓêÆP drב¶cken. Daraufhin
kבÀnnen Sie dann einen Text eingeben ΓêÆ drב¶cken Sie Esc und dann Return als
Bestבñtigung. Dann ist das Feld der Aktuellen Datei leer.

Nun soll der Editor gestartet werden. Dazu halten Sie entweder
die rechte Maustaste gedrב¶ckt, wבñhrend mit der linken das
EditierenΓêÆSymbol doppelt angelickt wird, oder Sie drב¶cken
Control−E. Damit wird die − leere − aktuelle Datei bearbeitet.

Geben Sie nun das folgende Programm im Editor ein − bitte mit korrekter
GroבƒΓêÆ und Kleinschreibung!

Programm sichern

Wenn das komplette
Programm eingegeben ist,
fahren Sie mit der Maus den
Menב¶punkt Datei an, und
wבñhlen Sie den Unterpunkt
Sichern oder Sichern als.
Damit wird die Datei im
Speicher wieder zurב¶ck auf
Disk geschrieben.

Da dem Editor aber bisher noch
kein Name fב¶r die Datei bekannt
war, fragt er zuerst danach. Es
erscheint der GEM−Datei−Selektor,
in dem nun ein Name fב¶r den
Programmtext anzugeben ist.
Nehmen wir ERSTESPR.M und
speichern es im Ordner USER.

Nun kann der Editor verlassen werden. Dazu ist
entweder AlternateΓêÆX zu drב¶cken oder im Menב¶
Beenden anzuwבñhlen.

Programm ב¶bersetzen

Damit von nun an in der Shell
das Ansprechen der Datei einfacher
wird, machen wir das Modul zur
Arbeitsdatei, indem N gedrב¶ckt oder
der entsprechende Menב¶punkt in
der Shell angewבñhlt wird.

Nun ist ein kleines Feld auf dem Desktop der Shell erschienen. Darin soll der
Name der Textdatei eingetragen werden. Dies kann manuell durch die Taste P
oder durch einen Doppelklick auf das Feld vorgenommen werden.

Nun genב¶gt ein Doppelklick auf das Ausfב¶hrenΓêÆSymbol oder ein
Druck auf die Taste A, um das Programm zu ב¶bersetzen und
dann zu starten (natב¶rlich kann das ב£bersetzen auch erst durch
einen separaten Compiler−Aufruf erreicht werden). Der Compiler wird
gestartet und zeigt in etwa folgendes Bild:

Nehmen wir aber vorsichtshalber an, daבƒ das Programm nicht auf Anhieb
fehlerfrei ist. In diesem Fall wird der Editor automatisch aufgerufen und zeigt
Ihnen mit dem Cursor die Fehlerposition an. Auבƒerdem ist oben in invertierter
Schrift die Fehlermeldung des Compilers zu sehen. Korrigieren Sie den Text,
und gehen Sie dann erstmal wieder vor, wie schon beschrieben (Text
speichern, Editor verlassen, Programm ausfב¶hren/ב¶bersetzen).

Zur Ausfב¶hrung des Programms ist eigentlich nicht viel zu sagen: Daבƒ die
Ausgaben in ein Fenster geschrieben werden, haben Sie schon selbst bemerkt.
Vielleicht haben Sie auch schon ausprobiert, daבƒ das Fenster vergrבÀבƒert und
verschoben werden kann, wie Sie das so kennen? Die Standardausgaben (ב¶ber
das Modul InOut) fב¶hren immer auf dieses StandardΓêÆFenster, solange Sie un-
ter der Shell arbeiten (und nicht TOSIO extra importieren). Zusבñtzlich steht
ein WindowΓêÆModul zur Verfב¶gung, mit dem Sie auch mehrere Fenster beliebi-
ger GrבÀבƒen handhaben kבÀnnen. (Auבƒerdem gibt's ein TerminalΓêÆModul, das ohne
Fenster arbeitet.)

Nun wollen wir das Programm erweitern. Wir befinden uns in
der Shell. Dort aktivieren Sie erneut den Editor. Das geht nun
entweder durch Doppelklick auf das Editieren−Symbol oder die
Taste E.

Zurב¶ck im Editor, בñndern Sie die WriteStringΓêÆAnweisungen:

Nun soll erneut ב¶bersetzt werden. Dies kבÀnnte mit dem Menב¶punkt Ende &
Comp veranlaבƒt werden: Der Editor speichert den Text automatisch, und der
Compiler beginnt mit der ב£bersetzung. Aber es geht auch noch schneller: Der
Editor erlaubt es, den Compiler zu starten, ohne den
Text zu speichern und den Editor zu verlassen. Allerdings
wird dann auch mehr Speicherplatz benבÀtigt. Diese
Funktion wird im Menב¶ durch Compilieren oder durch
Drב¶cken von AlternateΓêÆD aktiviert. Wenn allerdings der
Speicher zum ב£bersetzen nicht ausreicht, meldet der Compiler einen
entsprechenden Fehler und Sie mב¶ssen mit der Funktion Ende & Comp.
vorliebnehmen.

Nun wird der Compiler aber einen Fehler melden: Der Cursor steht auf dem
Wort Space, und die Meldung oben weist darauf hin, daבƒ dieser Bezeichner
unbekannt ist. Er muבƒ natב¶rlich erst importiert werden. Dazu fב¶gen Sie hinter
dem InOut−Import noch folgende Zeile ein:

Wenn Sie wieder den Compiler starten, sollte er diesmal alles ohne Fehler
ב¶bersetzen. Verlassen Sie diesmal den Editor mit dem Befehl Ende & Ausf.
(Tastenbefehl: Alternate−A). Der Text wird automatisch gespeichert, der
Compiler ב¶bersetzt das Programm (wenn Sie das nicht schon vorher im Editor
getan haben), und dann wird das Programm ausgefב¶hrt.

Wenn Ihr Spieltrieb noch nicht erschבÀpft ist, kבÀnnen Sie ja mal einen Lauf-
zeitfehler im Programm erzwingen (beispielsweise durch eine Division durch
Null) ΓêÆ was dann passiert, kבÀnnen Sie im Kapitel 2.5 nachlesen.

Spaבƒeshalber kבÀnnen Sie auch mal das Make (s. Kapitel 2.7) ausprobieren:
Aktivieren Sie im ToolsΓêÆMenב¶ der Shell das Programm ModRef, oder drב¶cken
Sie dazu die Taste F1. In der dann erscheinenden SelektorΓêÆBox wבñhlen Sie ein
Programmodul aus, z.B. das neu erstellte ERSTESPR.M oder auch eines aus
dem DEMO− oder UTILITY−Ordner. Das Programm wird dann nach kurzer Zeit
wieder die Selektor−Box zeigen, worauf Sie entweder noch weitere Module
auswבñhlen oder das Programm durch Klick auf den AbbruchΓêÆKnopf beenden. Es
wurde nun eine Datei mit der Endung M2M in dem Verzeichnis erzeugt, wo Sie
das erste Modul ausgewבñhlt haben.

Suchen Sie die Datei mit der Endung M2M im Inhaltsverzeichnis, und ziehen
Sie sie dann auf das Ausfב¶hrenΓêÆSymbol. Erst wird das MakeΓêÆProgramm
gestartet, dann werden alle Module, die Sie vorher ausgewבñhlt hatten,
ב¶bersetzt und daraufhin das erste Hauptmodul gestartet. Wiederholen Sie dies,
wird das Modul gestartet, ohne erneut ב¶bersetzt zu werden ΓêÆ das Make
erkennt, daבƒ die Module bereits ב¶bersetzt sind.

Allerdings hat die Anwendung des Make hier noch keinen groבƒen Sinn ΓêÆ bei
einzeln zum Ausfב¶hren gebrachten Dateien funktioniert diese Erkennung, ob
das Modul schon ב¶bersetzt ist, sowieso schon direkt von der Shell aus ohne
Verwendung des Make. Und alle Module, die importiert werden, sind Bestand-
teile des MegamaxΓêÆSystems und deshalb auch schon ב¶bersetzt. Erst, wenn
mehrere eigene Module importiert werden, lohnt es sich, das Make intensiver
zu nutzen. Mehr dazu in Kapitel 2.7.

Noch ein Tip zum Starten von Programmen, deren Namen Sie zwar wissen
aber sie nicht erst umstבñndlich suchen wollen, vielleicht sogar erst noch
ב¶bersetzen mב¶ssen. Wenn wir Ihnen hier erzבñhlen, Sie sollen beispielsweise
das Programm TEXTDEMO starten, kבÀnnen Sie davon ausgehen, daבƒ sich
dessen Quelltext in dem Ordner DEMO oder UTILITY befindet. So kבÀnnen Sie
nun eine Arbeitsdatei wבñhlen (Taste N) und dort den Quelltextnamen (ohne den
Ordnernamen) eingeben (Taste P). Dieser wird in der Regel aus den ersten
acht Buchstaben des Modulnamens und der Endung ".M" bei Hauptmodulen
gebildet. Bei unserem Beispiel also TEXTDEMO.M. Nun drב¶cken Sie einfach die
Taste A oder machen einen Doppelklick aus das Ausfב¶hrenΓêÆSymbol. Dann wird,
falls das Modul noch nicht ב¶bersetzt wurde, der Compiler automatisch aktiviert,
daraufhin wird das Programm gestartet.

Diese Seite ist leer

Trifft dies nicht zu, gehenSie bitte wie folgt vor:

Beschaffen Sie ein Blatt Papier (DIN A5). Prב¶fen Sie, ob das Blatt leer, d.h., frei von
Buchstaben, ist. Lochen Sie das Blatt mittig. Ein Bב¶rolocher leistet hierbei gute Dienste. Heften Sie das von Ihnen erzeugte Blatt auf diese Seite. Sie muבƒ vollstבñndig verdeckt
werden. Danke.

VersבñumenSie nicht, diesenHinweis auf dieser Seite nachzutragen, damit die Betriebssicherheit Ihres Handbuchs auchweiterhingewבñhrleistet bleibt.

2.2 Shell

ב£ber die ModulaΓêÆShell steuern Sie die einzelnen Komponenten des ModulaΓêÆ
Systems: Editor, Compiler, Linker... Die Shell unterstב¶tzt Sie dabei nicht nur
durch die GEMΓêÆBenutzeroberflבñche, sondern erledigt vieles auch automatisch
fב¶r Sie ΓêÆ etwa den Aufruf des Editors nach ב£bersetzungsfehlern oder das
"heimliche" Linken (Binden) eines Moduls vor der Ausfב¶hrung.

Aufruf der Shell

Wir gehen davon aus, daבƒ Sie sich eine Arbeitsdiskette zusammengestellt ha-
ben (siehe Kapitel 2.1). Wenn Sie alle dort beschriebenen Vorbereitungen
getroffen haben, klicken Sie die Modula−Shell MM2SHELL.PRG doppelt an. Das
Laden der Shell kann − je nach Konfiguration − eine Weile dauern, falls weitere
Module resident geladen werden (siehe 2.1). Wenn die Shell betriebsbereit ist,
meldet sie sich mit einer Menב¶zeile und einem neuen Desktop. Es ist zu beach-
ten, daבƒ sich im Verzeichnis der Shell zumindest immer die Dateien
MM2SHELL.RSC und MM2SHELL.M2P befinden.

Das Shell−Desktop

Das Monitor-
bild, das die
Shell Ihnen
zeigt, erinnert
Sie wahr-
scheinlich ein
wenig an das
GEM−Desktop:
Am oberen
Rand des Bild-
schirms gibt
es eine Menב¶-
zeile; darunter
eine Arbeits-
flבñche, auf der allerlei Gerבñte 'herumstehen'. Verschaffen wir uns erstmal
einen ב£berblick ב¶ber das Inventar:

Die Diskettensymbole erfב¶llen eine Funktion, die Sie schon vom
GEM kennen ΓêÆ sie reprבñsentieren die Massenspeicher, also Dis-
ketten, Festplatte oder RAM−Disk. Wenn Sie einen Kasten dop-
pelt anklicken, wird das Inhaltsverzeichnis in einem Fenster angezeigt. Die Na-
men der Symbole werden ב¶brigens von denen des GEMΓêÆDesktops ב¶bernommen.

Ebenso vertraut sollte Ihnen der Abfalleimer sein. Wie beim
GEMΓêÆDesktop kann auch hier alles MבÀgliche hineingeworfen wer-
den.

Einige Unterschiede zum Desktop gibt es aber doch. Die Inhaltsverzeichnisse
kבÀnnen nur als Text dargestellt werden und nicht auch als Symbole (Icons).
Auch eine Sortierung nach Datum, GrבÀבƒe oder Extension ist z. Zt. nicht mבÀg-
lich (aber wenn Sie wollen, kבÀnnen Sie das selbst בñndern ΓêÆ doch dazu mehr im
Kapitel Fב¶nf). Einzelne Dateien lassen sich wie gewohnt selektieren (einfach
anklicken) oder als Objekte auf andere schieben. Die Erweiterung der Selektion
geschieht, wie ב¶blich, durch Festhalten der ShiftΓêÆTaste beim Anklicken. Auf
dem GEMΓêÆDesktop ist es auבƒerdem mבÀglich, mehrere Dateien auf einmal zu
selektieren, indem neben die Datei−Symbole bzw. −Namen gezeigt und mit
festgehaltener Maustaste ein Gummiband um die gewב¶nschten Dateien gezogen
wird. In der Modula−Shell kann nicht neben die Namen geklickt werden − statt
dessen wird diese Multi−Selektion durch Festhalten der Control−Taste erreicht.

Wird eine einzelne Datei selektiert, erscheint ihr Name
ב¶brigens auch in der Anzeigebox fב¶r die aktuelle Datei.
Je nachdem, ob es eine ausfב¶hrbare Datei ist (Program-
me, Module, Make−, Batch− und Parameter−Dateien) oder nicht, wird sie als
CODE oder TEXT eingetragen. Die aktuelle Datei spielt bei der Aktivierung der
ShellΓêÆFunktionen ב¶ber Tastaturkommandos eine Rolle. Sie kann auch manuell
bestimmt werden durch Control−P oder einen Doppelklick auf das Anzeigefeld.

Teilweise wird die aktuelle Datei auch durch andere Shell−Operationen neu
definiert. Beispielsweise wird nach der Compilierung eines Moduls der erzeugte
Code zur aktuellen CodeΓêÆDatei, so daבƒ sich dann, ohne langes Suchen in den
Disk−Verzeichnissen nach der Datei, das Modul bequem durch Control−A oder
einen Doppelklick auf das Ausfב¶hrenΓêÆSymbol bei gleichzeitigem Festhalten der
rechten MausΓêÆTaste starten lבñבƒt.

Hinter dem Resident−Symbol verbirgt sich der Zugriff auf die
residenten und geladenen Module in der Shell. Durch das בûffnen
(Doppelklick) erhבñlt man ein Fenster, das die z. Zt. geladenen
Module und Programme zeigt ΓêÆ es sind Kopien der ausfב¶hrbaren CodeΓêÆDateien,
die von Disk geladen wurden, um schneller verfב¶gbar zu sein. Genauso wie die
Dateien der DiskΓêÆInhaltsverzeichnisse kבÀnnen die geladenen Module durch
Ziehen in den Abfalleimer aus dem Speicher (der Shell) entfernt werden oder
umgekehrt Code−Dateien aus Disk−Fenstern auf das Resident−Symbol oder
dessen Fenster gezogen werden, um sie neu zu laden. Das Resident−Fenster
kann auch durch Drב¶cken der Taste R geבÀffnet werden.

Durch Festhalten der AlternateΓêÆTaste beim בûffnen des ResidentΓêÆFensters
werden − statt nur der dazugeladenen − alle Module, die zum dem Zeitpunkt
geladen oder resident in der Shell eingelinkt sind, angezeigt − diese residenten
Module kבÀnnen jedoch nicht entfernt werden (das erreichen Sie nur, indem Sie
die Shell, in welche sie alle fest eingebunden sind, verlassen).

Auf das Linken gehen wir in Kapitel 2.6 intensiver ein − hier nur
als Information, daבƒ damit das LinkerΓêÆProgramm gestartet wird,
welches ein Modul so vorbereitet, daבƒ es danach auch auבƒerhalb
der ModulaΓêÆShell ausgefב¶hrt werden kann. Ein Doppelklick oder Druck auf die
Taste L bewirkt das Linken der aktuellen Arbeitsdatei.

Bleibt noch das Scannen−Symbol, das zur Suche nach Laufzeit-
fehlern dient. Nבñheres dazu in Kapitel 2.5. Um den Scanner fב¶r
die Arbeitsdatei zu starten, kann ein Doppelklick darauf erfolgen
oder die Taste S gedrב¶ckt werden. Nach einem erfolgten Laufzeitfehler in
einem Programm kann der dabei gefב¶hrte FehlerΓêÆDialog durch zusבñtzliches
Festhalten der Shift−Taste nochmal aktiviert werden.

Schlieבƒlich finden Sie auf dem Bildschirm die Symbole Editieren, Compilieren
und Ausfב¶hren, deren Bedeutung Sie bereits im Kapitel "Ein erstes Programm"
erfahren haben. Auch sie werden durch ihre Anfangsbuchstaben E, C und A
ב¶ber die Tastatur oder durch Doppelklick aktiviert, um die betreffende Opera-
tion mit der aktiven Arbeitsdatei auszulבÀsen.

Die Arbeitsdateien sind ein bequemes Mittel, um abwech-
selnd verschiedene Module zu bearbeiten. Es kבÀnnen bis
zu zehn von ihnen in der Shell angesprochen werden. Die Arbeitsdateien
werden in kleinen Feldern angezeigt, die durch Anklicken oder durch Drב¶cken
der zugehבÀrigen Tastenziffer angewבñhlt werden kבÀnnen.

Ist eine Arbeitsdatei selektiert (die Ziffer des Feldes ist zur Kontrolle
invertiert), kann ein bequemer Doppelklick auf die Symbole Editieren,
Compilieren, Ausfב¶hren, Linken oder Scannen, oder der Druck auf einen der
entsprechenden Anfangsbuchstaben, die gewב¶nschte Operation bezב¶glich der
Arbeitsdatei auslבÀsen. Dieselben Funktionen kבÀnnen durch zusבñtzliches
Festhalten der Control−Taste oder der rechten Maus−Taste statt dessen auf
die aktuelle Datei angewandt werden.

Natב¶rlich muבƒ eine Datei nicht erst zur aktuellen oder Arbeitsdatei ernannt
werden, um sie beispielsweise in den Editor zu laden. Wie beim Kopieren von
Dateien kבÀnnen die Eintrבñge aus den Fenstern auch direkt auf die Symbole
gezogen werden.

Ein Doppelklick auf Dateien ist auch mבÀglich: Je nach Art der Datei
ΓêÆ ausfב¶hrbar oder nicht ΓêÆ wird sie gestartet oder in den Editor geladen.
Dateien ohne Extension werden dabei wie Code−Dateien behandelt.

Zu Beginn sind noch keine Arbeitsdatei−
Felder auf dem Desktop vorhanden. Diese
mב¶ssen erst durch Drב¶cken der Taste N
oder Anwבñhlen des Menב¶punkts neue
Arbeitsdatei erzeugt werden. Entsprechend
kבÀnnen sie mit lבÀsche Arbeitsdatei oder
der Taste Delete wieder entfernt werden.

Ein Modul wird alsdann als Arbeitsdatei bestimmt, indem entweder eine Quell-
textdatei auf ein solches Arbeitsfeld gezogen oder nach Drב¶cken der Taste P
ihr Name manuell eingegeben wird.

Die restlichen Funktionen des DateiΓêÆMenב¶s entsprechen denen des GEMΓêÆ
Desktops, die jeweils rechts aufgefב¶hrten Tastencodes dokumentieren eine
optionale Anwahl ב¶ber die Tastatur.

ב£brigens kבÀnnen alle Objekte einschlieבƒlich der Arbeitsdateifelder auf dem
Shell−Desktop beliebig positioniert werden, beim Verlassen der Shell werden
dann − auf Wunsch − alle Einstellungen gesichert.

Ausfב¶hren von Programmen und anderen Dateien

Zum Ausfב¶hren einer Datei ziehen Sie beispielsweise den Eintrag aus dem Datei-
verzeichnis auf das Ausfב¶hrenΓêÆSymbol. Auf diese Weise kבÀnnen Sie sowohl
ב¶bersetzte Module ausfב¶hren, die dann automatisch mit den benבÀtigten Impor-
ten gebunden werden, als auch komplett gebundene (gelinkte) Programme. Eine
andere MבÀglichkeit, Dateien zu starten, besteht darin, einen Doppelklick auf
den Eintrag im Fenster durchzufב¶hren.

Es ist auch mבÀglich, Quelltextdateien zum Ausfב¶hren zu bringen ΓêÆ in diesem
Fall wird erst nach dem vermutlichen Code−Dateinamen gesucht (dieser wird
aus dem QuelltextΓêÆNamen und den mבÀglichen Endungen der CodeΓêÆModule
gebildet); wird er gefunden und ist das Datum der CodeΓêÆDatei jב¶nger als das
der Quelltextdatei, wird die CodeΓêÆDatei sofort ausgefב¶hrt, ansonsten wird vor-
her der Quelltext automatisch ב¶bersetzt. Dies funktioniert auch bei der aktiven
Arbeitsdatei (die ja immer ein Quelltext sein muבƒ), indem ein Doppelklick auf
das Ausfב¶hrenΓêÆSymbol getבñtigt oder die Taste A gedrב¶ckt wird. Voraussetzung
fב¶r die Funktionalitבñt dieses Mechanismus ist eine allzeit korrekt eingestellte
Systemzeit im Computer. Wie dies erreicht wird, erfahren Sie im Kapitel 2.7
bei der Anwendung des Make.

Neben echten CodeΓêÆDateien und deren Quelltexten kבÀnnen auבƒerdem MakeΓêÆ,
BatchΓêÆ und ParameterΓêÆDateien "ausgefב¶hrt" werden:

* Wird eine MakeΓêÆDatei (Endung M2M) ausgefב¶hrt, startet die Shell das MakeΓêÆ
Programm, welches dann prב¶ft, ob Module, die in der MakeΓêÆDatei aufge-
fב¶hrt sind, neu ב¶bersetzt werden mב¶ssen (siehe Kapitel 2.7). Ist dies der
Fall, startet die Shell daraufhin den Compiler, der dann alle notwendigen
Module ב¶bersetzt ΓêÆ es sei denn, es tritt ein Fehler auf: Dann wird der
Vorgang abgebrochen, der Fehler im Editor angezeigt, und der Make−Vorgang
muבƒ nach der Korrektur wiederholt werden.

* Eine BatchΓêÆDatei (Endung M2B) enthבñlt eine Reihe von Anweisungen, die mit
einem Texteditor erstellt werden kבÀnnen. Mit ihr kבÀnnen die Suchpfade fב¶r
Compiler, Editor und Programme sowie die Eintrבñge des ToolΓêÆMenב¶s bestimmt
und andere Programme (auch Compiler, Linker, Make) gestartet werden.
Nבñheres weiter unten.

* Eine ParameterΓêÆ oder ProjektΓêÆDatei hat die Endung M2P und enthבñlt die Ein-
stellungen der Shell, wie Arbeitsdateien, Fensterpositionen, Parameter fב¶r
Editor, Shell, Compiler usw. Diese Dateien werden von der Shell durch das
Sichern der Einstellungen erzeugt. Wird eine solche Datei "ausgefב¶hrt",
werden alle darin enthaltenen Einstellungen von der Shell ב¶bernommen.

Diese Art des Ausfב¶hrens von Quelltexten, MakeΓêÆ, BatchΓêÆ und Parameterdateien
ist auch bei den im ToolsΓêÆMenב¶ eingetragenen Funktionen mבÀglich: Wird
beispielsweise eine Datei DEMO.M2M als Tool eingetragen, wird bei ihrer
Aktivierung ב¶ber das ToolsΓêÆMenב¶ der MakeΓêÆVorgang eingeleitet, so, als wenn
die Datei auf das Ausfב¶hrenΓêÆSymbol gezogen oder doppelt angeklickt worden
wבñre.

Ausfב¶hren speziell von CodeΓêÆDateien

Vom GEMΓêÆDesktop her ist Ihnen bekannt, daבƒ Dateien mit den Endungen APP,
PRG, TOS und TTP ausfב¶hrbar sind. Diese Programme sind mit anderen Ent-
wicklungssystemen (natב¶rlich auch mit Megamax ModulaΓêÆ2) erstellt worden und
haben alle ein einheitliches Dateiformat, das vom Betriebssystem (GEMDOS )
verstanden wird, und somit kבÀnnen sie vom Desktop oder auch von anderen
Benutzeroberflבñchen (Shells) aus bequem gestartet werden. Diese Programme
haben alle erforderlichen Routinen fest eingebunden und definieren beispiels-
weise auch ihren eigenen Stack−Bereich.

Vom ModulaΓêÆCompiler ב¶bersetzte Module sind dagegen noch nicht gelinkt
(gebunden), so daבƒ sie auch nicht ohne weiteres vom GEMΓêÆDesktop oder einer
anderen Shell gestartet werden kבÀnnen, weil sie in der Regel dieses fremde
Format nicht kennen. Deshalb verdienen diese Code−Module auch keine der
bekannten ProgrammΓêÆEndungen. Ausfב¶hrbar sind die ב¶bersetzten Module

Die ב¶bersetzen CodeΓêÆModule kבÀnnen, entsprechend den gelinkten Programmen,
die Endungen MOD (analog zu APP und PRG), MOS (TOS) oder MTP (TTP)
tragen. Wird also eine Datei mit einer dieser Endungen unter der Shell
ausgefב¶hrt, wird sie wie die gelinkten Programme unter dem GEMΓêÆDesktop
behandelt: Bei MOSΓêÆDateien wird der TOSΓêÆModus (weiבƒer Hintergrund, Maus
aus, BlinkeΓêÆCursor an) aktiviert, bei MTPΓêÆDateien wird zusבñtzlich nach einer
Kommandozeile (Argumentzeile) fב¶r das Programm gefragt. Wird ein
CodeΓêÆModul an den Linker zum Binden ב¶bergeben, erzeugt dieser passend zur
Endung den entsprechenden Programmnamen (Bsp: "TEST.MOS" wird zu
"TEST.TOS").

Falls Ihnen ב¶brigens andere Endungen besser vertraut sind (OBJ, OBM, SYM,
usw.), kבÀnnen Sie in Kapitel Fב¶nf nachlesen, wie einfach Sie dies dem
MegamaxΓêÆSystem beibringen kבÀnnen.

Der Linker kennt noch eine weitere Endung: Aus MAC erzeugt er gelinkte
Dateien der Endung ACC; dies ist vorteilhaft, wenn Sie Accessories erzeugen
wollen ΓêÆ diese dב¶rfen in der Regel nicht ausgefב¶hrt, sondern nur als ACCΓêÆ
Dateien beim Booten des Rechners vom GEM aktiviert werden (es sei denn,
Sie verwenden die Funktion PrgCtrl.Accessory() zur Abfrage, ob das Programm
als normale Anwendung oder als Accessory gestartet wurde).

Durch das Festhalten der ShiftΓêÆTaste beim Starten erhalten Sie die MבÀglichkeit
zur Eingabe einer Argumentzeile (Command Line) auch bei Programmen der
Endungen MOD, MOS, APP, PRG und TOS.

Ein Problem, das noch nicht ganz zufriedenstellend gelבÀst wurde, ist die Wahl
des aktuellen Verzeichnisses fב¶r zu startende Programme. So gibt es Pro-
gramme, die als Hilfsprogramme der Shell dienen und die oft gerne stan-
dardmבñבƒig auf den in der Shell aktuellen Pfad (der durch das oberste offene
Disk−Fenster bestimmt wird) zugreifen wollen, beispielweise, wenn sie den
GEM−Datei−Selektor anzeigen. Andererseits gibt es Anwendungen, die weitere,
dazu gehבÀrende Dateien nachladen wollen, wie zum Beispiel GEMΓêÆResourceΓêÆ
Dateien (Endung RSC). Damit sie diese Dateien finden, ist es in der Regel so
zu lבÀsen, daבƒ sie im Verzeichnis gesucht werden, in dem auch das Programm
selbst steht. Davon macht beispielsweise auch die Modula−Shell Gebrauch: Sie
sucht bei ihrem Start die Dateien MM2SHELL.RSC und MM2SHELL.M2P im zu
dem Zeitpunkt aktuellen Verzeichnis, welches normalerweise auch dasjenige
ist, in welchem die Shell selbst steht, weil ja auch im GEM−Desktop das ent-
sprechende Fenster obenauf offen liegen muבƒ, damit die Shell gestartet werden
kann.

Nun gibt es aber auch beim GEMΓêÆDesktop die MבÀglichkeit, Programme nicht
aus dem vordersten, aktiven Fenster zu starten: Zielt man beim Starten auf
ein Programm in einem inaktiven Fenster und hבñlt dabei die rechte MausΓêÆTaste
fest, wird das Programm gestartet, wבñhrend das vordere Fenster den aktuellen
Pfad bestimmt. Dies machte sogar den Entwicklern des TOS bei ATARI
Schwierigkeiten, denn je nach Version des TOS gibt es verschiedene Resultate:
Einmal wird das Programm ב¶berhaupt nicht gestartet, ein anderes Mal kann es
seine RSC−Datei nicht finden.

Die Megamax−Shell geht nun so vor: Wird das Programm von einem Fenster
gestartet, wird immer der Pfad zum aktuellen, von dem das Programm
stammt. Ebenso wird verfahren, wenn eine Arbeitsdatei gestartet wird. Wird
die aktuelle Datei aufgerufen, hבñngt der aktuelle Pfad vom eingegebenen
Dateinamen ab: Ist ein Pfadname im Dateinamen enthalten, wird dieser
aktiviert. Ist kein Pfadname enthalten, wird wiederum derjenige verwendet, von
dem das Programm gestartet wird (das funktioniert, weil die Programme dann
in den Ordnern gesucht werden kבÀnnen). Dies macht bei der aktuellen Datei
nur dann einen Unterschied, wenn ihr Name manuell eingegeben wurde (durch
Doppelklick auf dessen Feld oder mittels Control−P); beim Benennen der
aktuellen Code−Datei durch Anklicken im Fenster oder nach einem Make− oder
ב£bersetzungsvorgang wird immer der vollstבñndige Pfadname mit ב¶bernommen.

Wollen Sie also ein bestimmtes Programm starten, das Sie nicht erst in den
Ordnern suchen wollen, brauchen Sie nur die aktuelle Datei zu bestimmen,
indem Sie den Namen des Programms (mit Endung, aber ohne Pfad) eingeben
(ControlΓêÆP) und dann starten (ControlΓêÆA). Wollen Sie gar erreichen, daבƒ ein
Programm einen bestimmten aktuellen Pfad erhבñlt, kann dieser bei der
Bestimmung der aktuellen Datei als Pfad mit eingegeben werden. Dann wird
dieser Pfad zum aktuellen, das Programm wird jedoch, wenn es dort nicht
vorhanden ist, weiterhin in den anderen Ordnern gesucht und von dort
gestartet.

Bei den Systemprogrammen (Compiler, Linker, Make, Editor) und den unter
dem ToolsΓêÆMenב¶ eingetragenen Programmen verhבñlt es sich noch etwas anders.
Da die Systemprogramme als feste Bestandteile des Entwicklungssystems mit
der Shell in besonderer Weise kommunizieren bzw. die Tools oft בñhnliche
Funktionen erfב¶llen, kann ihnen der aktuelle Pfad praktisch egal sein. Aus
diesem Grund wird bei ihren Aufrufen normalerweise kein neuer aktueller Pfad
eingestellt, statt dessen bleibt der Pfad der Shell (oberstes Fenster) aktiv.
Damit nun aber auch andere Editoren oder Tools ihre benבÀtigten Dateien (z. B.
RSC) nachladen kבÀnnen, gibt es auch hier die MבÀglichkeit, ihren aktuellen Pfad
zu definieren: Ist ein Systemprogramm oder ein Tool mit einem Pfadnamen
eingetragen, wird dieser Pfad beim Start aktiviert, ansonsten wird der Pfad
der Shell beibehalten.

Um allgemein das Wechseln des Aktuellen Pfades beim Start eines Programms
zu verhindern, muבƒ die AlternateΓêÆTaste bei Aktivierung der Ausfב¶hrenΓêÆFunktion
festgehalten werden.

Programmaufruf und −abbruch bei gelinkten Programmen

Wird ein gelinktes Programm ausgefב¶hrt, geschieht dies, wie vom
GEM−Desktop her gewohnt: Das Programm wird in den Speicher geladen, falls
dies nicht schon vorher geschehen ist (siehe Laden von Code−Dateien), dann
wird dessen BSSΓêÆBereich (Speicher fב¶r die globalen Variablen) gelבÀscht,
zuletzt wird es gestartet. Endet das Programm, wird zur Megamax−Shell
zurב¶ckgekehrt.

Tritt ein fataler Fehler im aufgerufenen, gelinkten Programm auf, so daבƒ eine
68000ΓêÆException (BusΓêÆFehler, AdreבƒΓêÆFehler und weitere von dem Programm
nicht abgefangene Fehler) ausgelבÀst wird, erscheint statt der vom DesktopΓêÆ
Start gewohnten BבÀmbchen die ScannerΓêÆBox (siehe Kapitel 2.5), in der aber
dann keine Lokalisation der Fehlerstelle ב¶ber Back und Frwd mבÀglich ist.
Wבñhlen Sie dann Quit, finden Sie sich in der Shell wieder. Dann kann es aber
sein, daבƒ die Maus nicht mehr sichtbar ist oder andere unsinnige Effekte
eintreten. Wenn die Shell noch auf Eingaben reagiert, verlassen Sie die Shell,
z. B. mit Control−Q. Oft stellt dann das GEM−Desktop den Normalzustand
wieder her, so daבƒ Sie die MegamaxΓêÆShell erneut starten kבÀnnen. Bei solchen
Abstב¶rzen von Progammen ist es aber in der Regel immer das Sicherste, so
bald wie mבÀglich einen Neustart des Rechners, beispielsweise durch Drב¶cken
des RESETΓêÆTasters, zu veranlassen, weil es mבÀglich ist, daבƒ das fehlerhafte
Programm auch Speicherbereiche, die dem TOS oder der Shell reserviert sind,
unkontrollierbar ב¶berschrieben hat, was sich teilweise erst sehr spבñt
bemerkbar macht.

Das Binden der Module

Wird ein vom Compiler ב¶bersetztes Modul gestartet, mב¶ssen zuerst die von
ihm importierten Module dazugebunden (gelinkt) werden. Dies wird von der
Prozedur CallModule des Loader−Moduls, die die Shell zum Starten sowohl von
gelinkten Programmen als auch von ungelinkten Modulen aufruft, automatisch
erledigt: Jedes benבÀtigte Modul wird in den Speicher geladen, wird ein Modul
von mehreren anderen importiert, wird es selbstverstבñndlich nur einmal
geladen. Danach werden die Module gebunden, das heiבƒt, die Referenzen
zwischen den Modulen (dies sind die importierten Prozeduren und Variablen)
werden fest verkettet. Diesen Vorgang nennt man Load−Time−Linking, weil das
Binden (Linken) der einzelnen Objekt−Module bei jedem Laden in den Speicher
von neuem erfolgt. Dem gegenב¶ber steht das einmalige Linken im voraus, bei
dem das Ergebnis als eine Datei (gelinktes Programm) erzeugt wird.

Auf den ersten Blick nun erscheint es ineffektiv, bei jedem Start das Linken
durchzufב¶hren, anstatt dies einmal zu tun: Wird das Programm mehrmals
nacheinander ohne בänderungen gestartet, vergeht viel mehr Zeit durch das
wiederholte Laden der einzelnen Code−Module statt der einen gelinkten
Programmdatei. Dies trifft aber nur bedingt zu. Ein Vorteil im dynamischen
(LoadΓêÆTimeΓêÆ) Linken liegt darin, daבƒ die Fehlerbehandlung (Debugging) einfacher
zu gestalten ist, zweitens kבÀnnen so mehrere, abwechselnd gestartete
Progamme leichter Informationen untereinander austauschen, und zu guter
Letzt ist es oft auch zeitsparender. Das kommt daher:

Der Loader (bzw. dessen Funktion CallModule) lבñdt jedes benבÀtigte Modul nur
einmal, auch wenn es von mehreren Modulen importiert wird. Dies ist sinnvoll
und findet bei auch jedem normalen Linker anderer Entwicklungssysteme
Verwendung.

Die Megamax−Shell besteht nun wiederum selbst aus vom Megamax−Compiler
ב¶bersetzten Modulen, die lediglich durch den Linker in eine Datei zusammengefב¶gt
wurden. Nun bietet es sich an, diese schon im Speicher befindlichen Module bei
Bedarf mitzubenutzen, genauso wie dies mit den nachgeladenen Modulen
geschieht. Bedingung ist lediglich, daבƒ das LoaderΓêÆModul, das selbst ja auch
Bestandteil der Shell ist, ausreichend Informationen ב¶ber die in der Shell
befindlichen Module erhבñlt. Dies wurde beim Linken der Shell durch eine beson-
dere Einstellung (Linken ohne Optimierung) erreicht.

Wird also der Loader aufgerufen, ein Modul zu starten (z. B. durch Ansprechen
der Ausfב¶hrenΓêÆFunktion der Shell), geht er wie bereits oben beschrieben vor:
Zuerst wird nachgesehen, ob sich das geforderte Modul schon im Speicher
befindet. Normalerweise ist dies beim Hauptmodul noch nicht der Fall, also
wird es nachgeladen und der Loader merkt sich, daבƒ dieses Modul nun geladen
ist. Dann wird nachgesehen, welche Module importiert werden. Bei denen wird
genauso verfahren: Ist das Modul noch nicht im Speicher, wird es geladen und
dessen Importe ebenfalls berב¶cksichtigt.

Ist ein Modul schon im Speicher, wird es nicht weiter verfolgt − in diesem Fall
kann davon ausgegangen werden, daבƒ alle seine Importe ebenfalls schon
geladen sind. Es ist also nicht mבÀglich, auch nicht mit den LadeΓêÆ/EntladeΓêÆ
Funktionen des LoaderΓêÆModuls bzw. der Shell, daבƒ am Ende ein Modul im
Speicher verbleibt, dessen Importe nicht ebenfalls alle geladen sind!

Nach diesen Lade−Regeln nun werden die in der Shell vorhandenen Module
immer als bereits geladen (speziell: resident) behandelt. Daraus folgt, daבƒ ein
Modul, das nur Module importiert, die schon in der Shell befindlich eingebunden
sind, praktisch keine Ladezeit mehr hat, weil lediglich das Hauptmodul selbst
von Disk geladen werden muבƒ ΓêÆ das Binden dieses Moduls mit denen der Shell
geht so schnell, daבƒ Sie davon nichts merken.

Nach der Bindung aller Module werden zuerst, wie bei gelinkten Programmen,
alle globalen Variablen gelבÀscht (Pointer auf NIL, REALs auf 0.0) und dann alle
ModulkבÀrper aufgerufen, das am tiefsten liegende von den anderen importierte
Modul wird zuerst, das oberste, von der Shell ausgewבñhlte Modul zuletzt
initialisiert. Bei zirkularen Importen (A importiert B, B wiederum A) ist die
Reihenfolge undefiniert und kann jederzeit wechseln.

Wollen Sie die MבÀglichkeit nutzen, daבƒ mehrere durch CallModule gestartete
Anwendungen (Module) Daten ב¶ber gemeinsam importierte Module austauschen
(shared data ), mב¶ssen Sie verhindern, daבƒ diese gemeinsamen Module
jedesmal neu initialisiert werden und neuen Speicherplatz fב¶r ihre globalen
Variablen erhalten. Das erreichen Sie, indem Sie solche Module mit einer
besonderen CompilerΓêÆDirektive ($Y+, siehe Kapitel 3.4) ב¶bersetzen.

Wבñhrend der gesamten Initialisierungsphase und beim Start des Hauptmoduls
wird ein Stack verwendet, dessen GrבÀבƒe in Info/Umgebung unter StackgrבÀבƒe...
(fב¶r LoadΓêÆTimeΓêÆLinking) einstellbar ist. Tritt wבñhrend des Programmlaufs ein
StackΓêÆב£berlaufΓêÆFehler auf, kann der Stack also ohne Neuב¶bersetzung fב¶r den
nבñchsten Start verבñndert werden. Die Systemprogramme (Compiler, Linker,
Make sowie die Editoren GME und GEP ED) verwenden ב¶brigens eine eigene, _
fest in der Shell definierte StackgrבÀבƒe.

Resident−Laden von Code−Dateien

Wenn ein gestartetes Modul abgelaufen ist, wird es wieder aus dem Speicher
entfernt. Auch die von ihm importierten Module, die noch von der Diskette
nachgeladen wurden, bleiben natב¶rlich nicht im Speicher ΓêÆ bei einem neuen
Start des Moduls wird alles erneut geladen. Um bei hבñufiger Benutzung eines
Moduls diese Ladezeiten zu eliminieren, kבÀnnen Sie Module in den Speicher
laden. Dazu dient das ResidentΓêÆSymbol auf der Arbeitsflבñche. Das
ResidentΓêÆSymbol funktioniert ganz בñhnlich wie die Diskettensymbole. Sie
kבÀnnen...

* einen Dateieintrag auf das Ladesymbol schieben, um das Modul
in den Speicher zu laden (ControlΓêÆR lבñdt die aktuelle Datei). Es
ist auch mבÀglich, gelinkte Programme auf diese Weise zu laden;

* das Ladesymbol doppelt anklicken, um ein Fenster mit dem Verzeichnis der
geladenen Module zu בÀffnen;

* Eintrבñge aus diesem Fenster mit der Maus auf das Ausfב¶hrenΓêÆSymbol schie-
ben oder doppelt anklicken, um sie auszufב¶hren. Allerdings ist es auch mבÀglich,
ein Modul aus einem ganz normalen Dateifenster zur Ausfב¶hrung zu bringen ΓêÆ
die Shell (der Loader) ב¶berprב¶ft, ob das Modul schon geladen ist, und fב¶hrt
ggf. die geladene Version aus.

* Auבƒerdem ist es mבÀglich, Eintrבñge aus dem Verzeichnis der geladenen Mo-
dule in den Abfalleimer zu schieben, um sie wieder aus dem RAM zu lבÀschen.
Beachten Sie aber, daבƒ das Ladesymbol keine normale RAMΓêÆDisk darstellt ΓêÆ
beim Laden werden die Module bereits fב¶r die Ausfב¶hrung vorbereitet (gelinkt);
daher ist es nicht mבÀglich, ein geladenes Modul auf ein Diskettensymbol zu
schieben oder an den Linker zu ב¶bergeben!

Ein anderer Weg, Module und gelinkte Programme resident laden zu lassen, ist
das Eintragen eines LOAD−Kommandos in eine Batch−Datei (s. Abschnitt weiter
unten in diesem Kapitel). Dies ist eine bequeme MבÀglichkeit, regelmבñבƒig benבÀtigte
Module resident in den Speicher zu laden, solange man sich in der Modula−
Shell befindet.

Die so geladenen Module werden zwar in die schon residenten Module
eingebunden (gelinkt), jedoch nicht intitialisiert! Die Initialisierung mit Aufruf
der ModulkבÀrper wird weiterhin so vorgenommen, wie unter Binden der Module
beschrieben, also als wenn sie jedesmal bei Bedarf doch von Disk geladen
werden wב¶rden.

Zum Schluבƒ noch ein Tip: Wבñhrend der Programmentwicklung kבÀnnen Sie den
Entwicklungszyklus (Edieren ΓêÆ ב£bersetzen ΓêÆ Testen) deutlich beschleunigen,
falls Ihr Programm Module importiert, die nicht bereits in der Shell vorhanden

Das Laden ist meist dem Ablegen eines Moduls in der RAM−Disk vorzuziehen:
Ein Modul aus der RAMΓêÆDisk wird zur Ausfב¶hrung jeweils ein zweites Mal in
den RAM kopiert und belegt dann doppelten Platz. Allerdings wird beim Laden
bereits Platz fב¶r die globalen Variablen reserviert, der belegt bleibt, solange
das Modul im RAM verbleibt. Dies wiederum macht sich bei wenigen Program-
men deutlich bemerkbar (beispielsweise bei dem Programmeditor TEMPUS von
CCD).

Laden gelinkter Programme

Das Laden von gelinkten Programmen wird prinzipiell durch eine Sonderfunktion
des GEMDOS ermבÀglicht. Aufgrund einer konzeptionellen Schwבñche bei
besagter Funktion ist aber deren Anwendung leider nicht so "idiotensicher" wie
die des Ladens von Megamax−Modulen.

Das Problem ergibt sich bei der Reservierung des Stacks fב¶r die Programme:
Ein gelinktes Programm, das normal gestartet wird, wird an den Beginn des
grבÀבƒten freien Speicherbereichs geladen. Wird es dann aufgerufen, erhבñlt es
erstmal den gesamten freien Speicher hinter dem Programmcode fב¶r sich als
reservierten Speicher. Daraufhin berechnet es den fב¶r sich selbst benבÀtigten
Speicher und gibt den Rest wieder frei. Der selbst benבÀtigte Speicher besteht
in der Regel aus dem Platz fב¶r die globalen Variablen und dem Stack des
Programms.

Wird ein solches Programm nur geladen, muבƒ der Loader, der dies organisiert,
dafב¶r sorgen, daבƒ nur so viel Platz fב¶r das Programm reserviert bleibt, wie es
spבñter beim Start benבÀtigen wird, damit der Rest des Speichers frei bleibt fב¶r
weitere Anwendungen. Aufgrund der Konventionen aber muבƒ das Programm
erwarten kבÀnnen, daבƒ es den benבÀtigten Speicher fב¶r die Variablen und den
Stack direkt hinter dem Programmcode vorfindet (fב¶r die Experten: Die
Relozierung, die das GEMDOS beim Laden vornimmt, nimmt auch sofort die
Adreבƒbestimmung der globalen Variablen im BSSΓêÆSegment ΓêÆ welches in der
Regel direkt hinter dem Programmcode oder dem DATA−Segment liegt − vor,
so daבƒ dieser Bereich spבñter nicht mehr an eine andere Stelle verschoben
werden kann). Hier liegt das Problem: Es ist zwar allgemein mבÀglich, den
benבÀtigten Platz fב¶r die globalen Variablen zu ermitteln, die StackΓêÆGrבÀבƒe aber
kann nicht vorausgesehen werden. So muבƒ also beim Laden abgeschבñtzt
werden, wieviel Platz der Stack spבñter benבÀtigen wird. Zuviel Platz kann dem
Programm nicht schaden, nur wird der Platz ja schon beim Laden reserviert,
so daבƒ der verbleibende freie Speicher ggf. unnבÀtig eingeschrבñnkt wird.

Ist der Stack zu klein gewבñhlt, ist es mבÀglich (aber nicht sicher), daבƒ das
geladene Programm wבñhrend seines Aufrufs fehlerhaft arbeitet oder gar
abstב¶rzt (Programm reagiert nicht mehr auf Eingaben, oder es erscheinen die
BבÀmbchen und das Programm kehrt in die Shell zurב¶ck).

Gegebenenfalls muבƒ also zuerst ein geladenes Programm mit Vorsicht
angewendet werden (jedenfalls sollte es bei Unsicherheit nicht mit wichtigen
Originaldaten arbeiten, die es ja zerstבÀren kבÀnnte).

Die meisten Fremdprogramme verwenden einen Stack von 8 bis 16 KByte (auch
Tempus kommt beispielsweise mit einem Stack von 8KB, =8192, zurecht). So
reicht es oft aus, zur Sicherheit den Stack beim Laden in dieser GrבÀבƒe
vorzusehen. Erst, wenn sich ungewבÀhnliche Effekte bei der Benutzung der
geladenen Programme zeigen, sollte der Stack jeweils vor dem erneuten Laden
durch Verdoppelung erhבÀht werden.

Die Bestimmung des Stacks beim Laden von gelinkten Programmen erfolgt
durch den Wert, den auch der Loader beim Start von Modulen verwendet. Er
kann in den Umgebungsinformationen unter StackΓêÆGrבÀבƒe fב¶r LoadΓêÆTimeΓêÆLinking
bestimmt oder durch die Anweisung STACKSIZE in Batch−Dateien, am besten
direkt vor dem Laden des Programms mit LOAD, auf einen besonderen Wert
gesetzt werden.

Die Menב¶zeile der Shell

Die Menב¶zeile am oberen Bildschirmrand bietet die Menב¶punkte MM2Shell,
Datei, Parameter, Info und ggf. Tools an. Unter MM2Shell erreichen Sie wie
ב¶blich die Accessories sowie eine Meldung ב¶ber die Version der Shell. Der
Menב¶punkt Datei wurde schon weiter oben behandelt.

Unter Parameter finden sich:

Shell: Siehe unten.

Editor: Siehe Kapitel 2.3

Compiler: Siehe Kapitel 2.4

Linker: Siehe Kapitel 2.6

speichern: Sichert die Einstellungen aller Parameter, der Symbol− und Fenster-
positionen und der Umgebungseinstellungen, jedoch nicht den Status der
geladenen Module, der ב¶ber die Menב¶zeile abrufbaren Tools und der Such-
pfade (diese Einstellungen sind ב¶ber die BatchΓêÆDateien bestimmbar). Die
Einstellungen werden in der Datei gesichert, die zu dem Zeitpunkt als
Parameterdatei unter Parameter/Shell... eingestellt ist.

Die Raute bei den Tastenangaben im ParameterΓêÆMenב¶ zeigt ב¶brigens an, daבƒ
diese Funktionen mit der Alternate−Taste in Verbindung mit dem Buchstaben zu
erreichen sind, wבñhrend der Pfeil fב¶r die ControlΓêÆTaste steht.

Unter Info finden sich:

Umgebung: Siehe unten.

Hilfe: Zeigt den Inhalt der Textdatei MM2SHELL.HLP an, falls sich diese im
Verzeichnis der Shell befindet.

Unter Tools kבÀnnen Sie bis zu zehn eigene ausfב¶hrbare
Dateien eintragen (mittels der Anweisung Tool in einer
Batch−Datei). Diese erscheinen dann unter dem Tools−
Menב¶punkt und kבÀnnen auch ב¶ber die Funktionstasten an-
gewבñhlt werden.

Die Shell−Parameter (Parameter/Shell...)

Erzeuge Fenster:

Wurzel בÀffnet Fenster bei
Doppelklick in gewohnter
Weise. Der aktuelle Pfad
kann statt dessen ent-
weder durch die hiesige
Standardeinstellung oder
durch Festhalten der Shift−
Taste beim Doppelklick
geבÀffnet werden.

KopierΓêÆ und LבÀschbestבñtigung bestimmen, ob bei den entsprechenden Dateiope-
rationen eine Bestבñtigung gefordert werden soll.

Abbruch mit ControlΓêÆC: Ist diese Option aktiv, kבÀnnen von der Shell gestartete
Programme mit ControlΓêÆC abgebrochen werden, wבñhrend sie EinΓêÆ oder Ausga-
ben ב¶ber die Module TextWindows oder InOut durchfב¶hren. Auch ist es dann
mבÀglich, mit ControlΓêÆEnter Programme zu jeder Zeit abzubrechen ΓêÆ dies sollte
aber nur dann geschehen, wenn Control−C nicht wirkt und das Programm nicht
gerade Betriebssystemaufrufe (z.B. Zugriff auf die Disk oder Grafikausgaben
auf dem Bildschirm) durchfב¶hrt, da es sonst zu Fehlverhalten des Systems
kommen kann. Nבñhere Informationen im Definitionstext des Moduls UserBreak.

Anwender eines Drucker−Spoolers oder der Flexdisk sollten die Option Maximaler
Kopierpuffer gegebenenfalls deaktivieren, ansonsten bietet es sich fast immer
an, diese Option zu nutzen, denn dadurch wird bei Kopiervorgבñngen fast der
gesamte Speicherplatz verwendet, um den Kopiervorgang mבÀglichst schnell
durchzufב¶hren.

Unter Make wird der Name des Make−Programms eingetragen − dies ist in der
Regel MM2Make.

In Temp. Pfad sollte ein Ordnername eingetragen werden, in dem die Shell und
die Hilfsprogramme kurzzeitig kleine Dateien ablegen kבÀnnen. So legt Make
dort beispielsweise die Steuerdatei der evtl. zu ב¶bersetzenden Module fב¶r den
Compiler ab. Nach MבÀglichkeit sollte dieser Pfad auf einem schnellen Gerבñt
liegen, also eher auf einer RAM−Disk als einer Diskette − ein Pfad auf der
Harddisk reicht natב¶rlich auch aus.

Die BatchΓêÆDatei (mit der Endung M2B) ist diejenige, die ausgefב¶hrt wird, wenn
die darunter angegebene Parameterdatei (teilweise auch als Projekt−Datei
bezeichnet) aktiviert oder "ausgefב¶hrt" wird. Diese wiederum kann aktiviert
werden, indem sie − vorausgesetzt, sie hat die Dateiendung M2P − auf ge-
wohnte Weise (Doppelklick, Ziehen auf das Ausfב¶hrenΓêÆSymbol, Starten als
Tool) "ausgefב¶hrt" wird. Einen Sonderstatus genieבƒt die Parameterdatei

Um eine neue ParameterΓêÆ oder BatchΓêÆDatei zu erstellen, kבÀnnen Sie folgen-
dermaבƒen vorgehen: Tragen Sie eine beliebige Datei der Endung M2B als
BatchΓêÆDatei und ebenso eine der Endung M2P (z. B. MM2SHELL.M2P fב¶r die
Autostart−Parameter) als Parameterdatei ein. Dann verlassen Sie den Shell−
ParameterΓêÆDialog und wבñhlen Parameter/speichern... an. So werden die aktu-
ellen Einstellungen unter der gewבñhlten Parameterdatei gesichert.

Die Umgebungsinformationen (Info/Umgebung...)

Letzter Code/Lבñnge infor-
mieren ב¶ber die vom letzten
Compileraufruf erzeugte Code−
Datei und dessen Lבñnge.

Normalerweise wird der
aktuelle Pfad durch das
oberste, geבÀffnete DiskΓêÆ
Fenster bestimmt. Ist jedoch
keins offen, kann der Pfad
hier abgelesen oder auch geבñndert werden. Das בändern des Pfades hat keinen
Erfolg, wenn ein Fenster geבÀffnet ist ΓêÆ dieses hat dann Vorrang.

Die DefaultΓêÆMakeΓêÆDatei wird aktiviert, wenn in der Shell die Taste M gedrב¶ckt
wird oder wenn vom Editor (GEP_ED oder GME) aus die Make−Funktion ange-
wבñhlt wird. Das Aktivieren einer MakeΓêÆDatei bewirkt den Aufruf des MakeΓêÆ
Programms, welches dann aufgrund der Informationen aus der Make−Datei (mit
Endung M2M) prב¶ft, ob Dateien zu ב¶bersetzen sind und daraufhin dann den
Compiler dazu aufruft. Nבñheres in Kapitel 2.7.

Die StackΓêÆGrבÀבƒe fב¶r das LoadΓêÆTimeΓêÆLinking wird den Anwendungsmodulen zur
Verfב¶gung gestellt, wenn sie unter der Shell gestartet werden (gelinkte Program-
me haben bereits intern eine feste Einstellung − beim Linken von Megamax−
Modulen kann dieser Wert ebenfalls bestimmt werden, allerdings in den Lin-
ker−Optionen). Der anfangs eingestellte Wert von 16 K Bytes kann zu klein
sein, wenn das Programm rekursiv arbeitet oder groבƒe Datenstrukturen als
lokale Variablen verwendet (Sie erfahren dies dann wבñhrend des Programm-
laufs durch die Fehlermeldung "StackΓêÆב£berlauf").

Taste nach TOS−Programmen: Wartet beim Ende von TOS−Programmen auf
einen Tastendruck, damit eventuelle Ausgaben noch gelesen werden kבÀnnen.

Der aktuell freie Speicherplatz wird in zwei Werten angezeigt. Der linke gibt
den grבÀבƒten zusammenhבñngenden Bereich, der rechte den gesamten freien
Platz an.

Tasten−Funktionen

Zusammenfassend haben folgende Tasten in der Shell eine Funktion:

Anfangsbuchstaben der Symbole: Sie bearbeiten alle die jeweils aktive Arbeits-
datei, es sei denn, es wird zusבñtzlich die ControlΓêÆTaste gedrב¶ckt ΓêÆ dann wird
stattdessen die aktuelle Datei bearbeitet.

A Ausfב¶hren (von Programmen, Modulen, Make, Batch, Projektdateien)

Wird dabei Shift festgehalten, kann eine Argumentzeile (wie
bei TTP bzw. MTP−Programmen) eingegeben werden, beim
Festhalten von Alternate bleibt der aktuelle Pfad erhalten.

C Compilieren (ב£bersetzen)

+ Compilieren, dann Ausfב¶hren

E Laden der Datei in den Editor

L Linken (Binden der Module zu einem Programm)

S Aktivieren des Scanners

Falls vorher bei einem Programmaufruf ein Laufzeitfehler
auftrat und die Scanner−Dialogbox erschien, kann durch Ein-
gabe von Shift−S der letzte Dialog wiederholt werden, um eine
andere Textposition anzuscannen (siehe Kapitel 2.5).

P Eingabe der ArbeitsΓêÆ oder aktuellen Datei ב¶ber Tastatur.

Weitere spezielle Funktionen, die nicht aus den Menב¶zeilen ersichtlich sind:

M Make−Vorgang mit der Default−Make−Datei einleiten.

Ctrl−R Laden der aktuellen Code−Datei.

R Anzeige der geladenen Module und gelinkten Programme.

Alt−R Anzeige aller im Speicher vorhandenen (residenten) Module.

Bleiben noch folgende versteckte Funktionen:

Esc Neuanzeige des Inhalts des obersten Fensters, z.B. nach Wechseln
einer Diskette;

Wבñhrend des Starts der Shell kann durch Druck auf diese Taste
verhindert werden, daבƒ Programme durch den StartΓêÆBatch geladen
werden.

Home Schlieבƒt das Verzeichnis des aktiven Fensters.

Clr (ShiftΓêÆHome) Schlieבƒt das aktive Fenster. Werden beide ShiftΓêÆ
Tasten festgehalten, werden alle Fenster geschlossen.

Ctrl−Q Beenden der Shell ohne Nachfrage zum Sichern der Einstellungen.

Batch−Dateien

In BatchΓêÆDateien kבÀnnen hבñufig benבÀtigte ShellΓêÆOperationen und ΓêÆEinstellungen
beschrieben und dann jederzeit zur Ausfב¶hrung gebracht werden. Auבƒerdem
werden hiermit die Suchpfade der Dateien fב¶r Shell, Editor, Compiler, Linker
und Make eingegeben. Die Batch−Datei ist ein normaler ASCII−Text, der alle
Anweisungen im Klartext enthבñlt, daher kבÀnnen Sie diese Datei mit dem
mitgelieferten Editor bearbeiten.

Eine besondere Batch−Datei ist diejenige, die in den Shell−Parametern unter
Batch−Datei eingetragen ist: Sie wird automatisch beim Start der Shell
ausgefב¶hrt. ב£blicherweise enthבñlt diese Datei Anweisungen, um Module (auch
gelinkte Programme) zu laden und um vor allem die Suchpfade zu bestimmen,
damit ב¶berhaupt ein Arbeiten in der Shell mבÀglich ist.

Im folgenden wird zunבñchst die Syntax der BatchΓêÆDateien beschrieben (in
BackusΓêÆNaurΓêÆForm, siehe Anhang A.6); anschlieבƒend erlבñutern wir die Funktion
der einzelnen Anweisungen:

Syntax der Batch−Dateien

anweisung = { IF SHELLSTART anweisung א½crא† | _

WAIT text א½crא† |

* text א½crא† |

SETPATH pfad א½crא† |

SETDRIVE laufwerk א½crא† |

SETDIR pfad א½crא† |

DELETETOOLS א½crא† |

TOOL dateiname א½crא† |

LOAD dateiname א½crא† |

UNLOAD dateiname א½crא† |

STACKSIZE cardinal א½crא† |

EXEC dateiname { argument} א½crא† |

IF EXITCODE integer anweisung א½crא† | _

DEFOUT { pfad } א½crא† |

IMPOUT { pfad } א½crא† |

MODOUT { pfad } א½crא† |

MAINOUTPUTPATH { pfad } א½crא† |

COMPILE dateiname א½crא† |

MAKE { dateiname } א½crא† |

LINKSTACKSIZE cardinal א½crא† |

NO OPTIMIZE א½crא† | _

PART OPTIMIZE א½crא† | _

FULL OPTIMIZE א½crא† | _

DRIVER [ '+' | 'ΓêÆ' ] dateiname א½crא† |

DELETEDRIVERS א½crא† |

LINK dateiname א½crא† |

DEFAULTPATH pfadΓêÆliste א½crא† |

DEFPATH pfadΓêÆliste א½crא† |

IMPPATH pfadΓêÆliste א½crא† |

MODPATH pfadΓêÆliste א½crא† |

SOURCEPATH pfadΓêÆliste א½crא† }.

pfadΓêÆliste = { א½crא† Leerzeichen { Leerzeichen} pfad }.

pfad = [ laufwerk ] [ 'ב¶' ] { [ name | '..' ] 'ב¶' } .

dateiname = pfad name

name = prefix [ '.' suffix ] (einfacher Dateiname ohne Pfad )

laufwerk = Buchstabe ':'

prefix = Bis zu acht Buchstaben oder Ziffern

suffix = Bis zu drei Buchstaben oder Ziffern

argument = Ein Wort (Text, der nicht durch Leerzeichen unterbrochen ist)

text = Beliebiger Text

cardinal = Positive, ganze Zahl (0 bis 2^32−1)

integer = Ganze Zahl (−32767 bis 32768)

Die Anweisungen sowie alle Teile von DateiΓêÆ und Pfadnamen dב¶rfen sowohl in
GroבƒΓêÆ als auch Kleinbuchstaben geschrieben sein.

Um einen Batch sowohl fב¶r die Erstinitialisierung fב¶r die Shell als auch allge-
mein verwendbar zu machen, ist es teilweise notwendig, bestimmte Funktionen
darin nur beim Start der Shell durchzufב¶hren. Wird die Anweisung
IF SHELLSTART vor eine normale Anweisung gestellt, wird sie nur berב¶ck- _
sichtigt, wenn der Batch beim Starten der Shell automatisch ausgefב¶hrt wird.

Mit WAIT wird der dahinter stehende Text in einer Alert−Box angezeigt und
erst bei Bestבñtigung des OKΓêÆKnopfs wird der Batch weiter abgearbeitet.

Teilweise ist es wב¶nschenswert, bestimmte DiskΓêÆVerzeichnisse als aktuelle
Pfade einzustellen. Jedes Laufwerk kann dabei ein eigenes aktuelles Verzeichnis
haben, zusבñtzlich gibt es ein aktuelles Laufwerk; das aktuelle Laufwerk bestimmt
mit seinem aktuellem Verzeichnis (Dir) den aktuellen Pfad. SETDRIVE wבñhlt
mit einem angefב¶gten Laufwerksbuchstaben das aktuelle Laufwerk, SETDIR
bestimmt, falls beim Pfadnamen kein Laufwerk angegeben ist, das aktuelle
Verzeichnis des aktuellen Laufwerks, sonst den Pfad des angegebenen Lauf-
werks − das aktuelle Laufwerk wird jedoch nicht gewechselt (so kann damit das

War das zu kompliziert? Dann andersrum: Normalerweise verwenden Sie
SETPATH. Damit geben Sie Laufwerk und Verzeichnis an, die dann zum
aktuellen werden. Das hat die gleiche Funktion wie die Eingabe des aktuellen
Pfads in den Umgebungsinformationen.

Wollen Sie aber auch die Pfade der anderen Laufwerke festlegen, verwenden
Sie fב¶r jedes Laufwerk SETDIR. Das wבñre beispielsweise nב¶tzlich, wenn Sie die
Disk−Fenster in der Shell mit Shift bzw. der Einstellung Erzeuge Fenster auf
aktuellem Pfad (s. ShellΓêÆParameter) בÀffnen wollen ΓêÆ dann wird der mit SETDIR
fב¶r das Laufwerk bestimmte Pfad geבÀffnet. Ebenso wird beim GEMΓêÆDateiΓêÆ
Selektor ab TOS 1.4 beim Anklicken eines Laufwerks dessen aktuelles
Verzeichnis angezeigt.

Die Eintrבñge im ToolsΓêÆMenב¶ kבÀnnen mit TOOL bestimmt werden. Bis zu zehn
Tools kבÀnnen eingetragen werden. Die Menב¶eintrבñge werden nacheinander auf-
gefב¶llt. Die dort aufgefב¶hrten Programme kבÀnnen durch die Menב¶anwahl oder
eine Funktionstaste bequem ausgefב¶hrt werden.

Fב¶r die Dateinamen bei TOOL gilt: Wird ein Pfad angegeben, wird beim Start
des Programms der Pfad zum aktuellen Pfad, ansonsten bleibt der in der Shell
gerade aktuelle Pfad erhalten.

Um alle ToolsΓêÆEintrבñge zu lבÀschen, dient die Anweisung DELETETOOLS.

Die LOADΓêÆAnweisung veranlaבƒt die Shell, das angegebene Modul in den Spei-
cher zu laden, so, als ob es auf das ResidentΓêÆSymbol gezogen wב¶rde. Die
Module stehen dann zum direkten Aufruf oder auch zum Import in andere
Module zur Verfב¶gung und mב¶ssen nicht wiederholt von Diskette geladen
werden. Besonders interessant ist die MבÀglichkeit, Editor und Compiler zu
laden ΓêÆ der Aufruf ist anschlieבƒend ohne Wartezeit mבÀglich. UNLOAD gibt ge-
ladene Module entsprechend wieder frei.

Mit EXEC kann ein Programm oder Modul gestartet werden. Wenn es endet, wird hinter der EXEC−Anweisung in der Batch−Datei fortgefahren. Nach der
Rב¶ckkehr kann ב¶ber IF EXITCODE der Rב¶ckgabewert des Progamms geprב¶ft
_ werden. Nur, wenn er zutrifft, wird die dahinter stehende Anweisung
ausgefב¶hrt. Dies kann zum Beispiel Verwendung finden, um auf abnorme
Abbruchbedingungen eines Programms zu reagieren: Jedes Programm kann
beim Terminieren einen IntegerΓêÆWert zurב¶ckgeben. Bei MegamaxΓêÆProgrammen
kann dies ב¶ber die Prozedur TermProcess aus dem Modul PrgCtrl geschehen.
Jedes Programm das normal terminiert, liefert als Rב¶ckgabewert (Exitcode)
Null. Nun kבÀnnten Sie ein Programm schreiben, das mit einem anderen Wert

EXEC A

IF EXITCODE 1 B _

Wird dieser Batch gestartet, lבñבƒt er A ausfב¶hren. Terminiert A, wird B nur
gestartet, wenn der Exitcode von A Eins ist.

STACKSIZE erlaubt die Einstellung der StackgrבÀבƒe, die gestarteten Programmen
zur Verfב¶gung gestellt wird. Normalerweise wird die StackΓêÆGrבÀבƒe in den
Umgebungsinfomationen (s.o.) bestimmt, jedoch kann es notwendig sein, diesen
Wert vor dem Starten bestimmter Module mit dem EXECΓêÆBefehl zu בñndern.

Ein ModulaΓêÆProgramm kann mit COMPILE und einem angefב¶gten QuelltextΓêÆ
(SourceΓêÆ) Namen ב¶bersetzt werden. Tritt dabei ein ב£bersetzungsfehler auf,
wird eine entsprechende Meldung angezeigt. Der Fehler kann dann wahlweise
ignoriert werden, so daבƒ der Batch bei der nבñchsten Anweisung fortfבñhrt oder
der Editor gestartet wird (dann ist die Batch−Abarbeitung abgebrochen und
muבƒ bei Bedarf erneut gestartet werden).

Mit DEFOUT, IMPOUT, MODOUT und MAINOUTPUTPATH kבÀnnen die
Ausgabepfade des Compilers abweichend von der Standard−Einstellung (siehe
Kapitel 2.4, Compiler) bestimmt werden. Allerdings werden sie nicht
automatisch am Ende des Batch−Laufs wieder auf ihre alten Werten gestellt.
DEFOUT, IMPOUT und MODOUT kבÀnnen nicht rב¶ckgבñngig gemacht werden,
hבÀchstens durch Neudefinition der Suchlisten (DEFPATH, IMPPATH,
MODPATH). Dagegen kann MAINOUTPUTPATH durch eine leere Pfadangabe
wieder ungב¶ltig gemacht werden. Nach einem CompilerΓêÆFehler mit Aufruf des
Editors (oder Abbruch des Batch−Laufs) wird diese Anweisung allerdings nicht
mehr ausgefב¶hrt ΓêÆ dann muבƒ ggf. die Einstellung des AusgabeΓêÆPfads in den
CompilerΓêÆOptionen (Parameter/Compiler) rב¶ckgבñngig gemacht werden.

Der Make−Vorgang kann durch die Anweisung MAKE gestartet werden. Wird
kein Name einer Make−Datei (Endung M2M, mit Hilfsprogramm ModRef
erstellt) angegeben, wird die Default−Make−Datei der Umgebungsinformationen
verwendet, ansonsten die angegebene. Bei einem Fehler in der Make−Datei
oder beim darauf folgenden ב£bersetzungsvorgang wird so verfahren, wie schon
oben bei der COMPILE−Anweisung beschrieben.

Um ein Programm im Batch zu binden, ist LINK zu verwenden. Der dahinter
anzugebende Modulname darf eine Pfadangabe enthalten. Ist dies der Fall, wird
die zu erzeugende gelinkte Programmdatei auf dem angegebenen Pfad erzeugt,
ansonsten dort, woher das angegebene Modul stammt. Der Optimierungsgrad,
die StackΓêÆGrבÀבƒe, die das gelinkte Programm verwenden soll sowie die einzu-
bindenden Treiber−Module werden normalerweise in der Dialogbox des Linkers

LINKSTACKSIZE bestimmt mit der angegebenen Zahl die StackgrבÀבƒe fב¶r das
zu linkende Programm; sie sollte mindestens 2000 (Bytes) betragen. Mit einer
der Anweisungen NO OPTIMIZE, PART OPTIMIZE oder FULL OPTIMIZE wird _ _ _
keine, verkב¶rzte bzw. vollstבñndige Optimierung des Programms erreicht. Nach
DRIVER kann ein Treiber− (Konfigurations−) Modul angegeben werden.
Insgesamt kבÀnnen bis zu acht solcher Module eingetragen werden. Dem
Modulnamen hinter DRIVER kann ein Plus− oder Minuszeichen vorangestellt
werden (ohne Leerzeichen!), je nachdem wird es als selektiertes oder
abgeschaltetes Modul eingetragen (nur selektierte Module werden beim Linken
als Treiber mit eingebunden) ist kein solches Zeichen vor dem Namen, wird
das Modul als selektiert ב¶bernommen. Ein bereits konfiguriertes Modul wird
nicht doppelt eingetragen, sondern die neue Definition ב¶berschreibt dann die
alte. Durch die Anweisung DELETEDRIVERS kבÀnnen allerdings alle TreiberΓêÆ
Eintragungen gelבÀscht werden.

Um die weiteren Eintrבñge der BatchΓêÆDatei zu erklבñren, holen wir etwas weiter
aus ΓêÆ als Vorwarnung spendieren wir eine neue ב£berschrift:

Suchpfade und Pfadlisten

Zu guter Letzt kבÀnnen Sie in der BatchΓêÆDatei verschiedene Pfadlisten angeben ΓêÆ
also Listen von Directories, die beim Suchen verschiedener Dateitypen abge-
sucht werden sollen. Vier dieser Pfadlisten werden ausschlieבƒlich vom ModulaΓêÆ
System selbst (Compiler, Linker) benutzt:

DEFPATH fב¶r ב¶bersetzte Definitionsmodule:

Hier sucht der Compiler die Definitionsdateien (Endung DEF)
der importierten Module.

Im ersten angegebenen Pfad legt der Compiler neu erzeugte
(ב¶bersetzte) Definitionsdateien ab.

IMPPATH fב¶r ב¶bersetzte Implementationsmodule,

MODPATH fב¶r ב¶bersetzte HauptΓêÆ (ProgrammΓêÆ) Module:

Auf diesen beiden Pfadlisten sucht der Linker (nicht der
Loader!) nach einzubindenden Modul−Codes, die vom zu
linkenden Programm importiert werden.

Im ersten angegebenen Pfad legt der Compiler neu erzeugte
(ב¶bersetzte) ImplementationsΓêÆ bzw. HauptΓêÆModulΓêÆCodes ab.

SOURCEPATH fב¶r alle Quelltexte (Sourcen):

Hier suchen Compiler und Editor nach den Quelltexten, wenn
diese nicht auf dem angegebenen Pfad zu finden sind.

Die ModulaΓêÆShell selbst (bzw. deren Loader) sucht alle Module, die ausgefב¶hrt
werden sollen, in der DEFAULTPATHΓêÆListe. Das gilt auch fב¶r Module, die per
LOAD−Anweisung in der Batch−Datei geladen werden sollen. Eventuelle LOAD−
Anweisungen in der BatchΓêÆDatei, die beim ShellΓêÆStart automatisch ausgefב¶hrt
wird, sollten also hinter der dort ΓêÆ notwendigerweise ΓêÆ aufgefב¶hrten
DEFAULTPATH−Definition stehen.

Auבƒerdem steht die DEFAULTPATHΓêÆListe Systemprogrammen, wie dem Make,
zur Verfב¶gung: Die Variable StdPaths im Modul ShellMsg enthבñlt eine kodierte
Form dieser Liste (vom Datentyp PathList). In der Dokumentation (Definitions-
modul) zum Modul Paths erfahren Sie, wie Sie durch einfachen Aufruf einer
Prozedur eine Datei in allen Verzeichnissen dieser (oder auch einer anderen)
Pfadliste suchen lassen kבÀnnen. Um auf einfache Weise anwenderfreundliche
Programme zu verwirklichen, ist die Benutzung dieser Suchfunktion vor dem
Zugriff auf Dateien sehr empfehlenswert. Um die Pfadliste fב¶r gelinkte
Programme, also auבƒerhalb der Shell, anzulegen, gibt es das Modul InitPathList
im UTILITY−Ordner.

Vorsicht!

Es ist unbedingt darauf zu achten, daבƒ nach einer PfadlistenΓêÆ
Anweisung die in den folgenden Zeilen aufgefב¶hrten Pfade alle
mindestens um ein Leerzeichen eingerב¶ckt sind und keine
Leerzeilen bis zum Ende der Liste vorkommen!

Die Syntax der Pfadnamen wird weiter unten erklבñrt fב¶r den Fall, daבƒ Sie mit
ihr noch nicht vertraut sind.

Wird ein Pfadname mit einem Sternchen (und einem darauf folgenden Ordner−
Trennstrich, also "*ב¶") angefב¶hrt, wird es von den Systemprogrammen
(Compiler, Make, Shell usw.) durch den Pfad der Shell ersetzt (dieser steht im
Modul ShellMsg). Damit kבÀnnen die Pfade so angegeben werden, daבƒ die Shell
zusammen mit ihren Unterverzeichnissen problemlos in jeden beliebigen Ordner
(einer ausreichend groבƒen Harddisk) kopiert werden kann und erstmal keine
Korrekturen an den Pfadlisten vorgenommen zu werden brauchen, um mit dem
System arbeiten zu kבÀnnen. Dies wurde ב¶brigens auch bei der Zusammen-
stellung des Megamax−Systems auf Ihren erworbenen Disketten ausgenutzt
(siehe die Batch−Datei MM2SHELL.M2B).

Am Ende der Pfadliste kann ein Fragezeichen als Dateiname eingetragen
werden. Dies bewirkt, daבƒ die GEMΓêÆDateiauswahlΓêÆFunktion (FileΓêÆSelektor)
aufgerufen wird, wenn eine gesuchte Datei nicht auf den vorigen Pfaden der
Liste gefunden werden kann.

Der Aufbau einer Pfadangabe ist zwar nicht Megamax−spezifisch, soll aber
doch noch kurz erlבñutert werden:

* Die Laufwerksangabe durch Laufwerksbuchstaben und Doppelpunkt ist optio-
nal; wenn sie fehlt, wird das gerade aktive Laufwerk benutzt.

* Der folgende Schrבñgstrich gibt an, daבƒ vom StammΓêÆInhaltsverzeichnis (auch
Wurzel− oder Root−Directory) des Laufwerks ausgegangen wird. Fehlt er, dann
beginnt der Pfad im gerade aktiven Verzeichnis, das sich der Atari zu jedem
Laufwerk einzeln merkt.

* Beginnen Sie im aktiven Verzeichnis, so kבÀnnen Sie zunבñchst ins
ב¶bergeordnete Verzeichnis heraufsteigen, indem Sie '..ב¶' folgen lassen.

* Nachdem nun der Ausgangspunkt des Pfades definiert ist, kבÀnnen Sie sich
von dort beliebig tief in Ordner (Subdirectories) 'hineinwב¶hlen'. Die Ordnerna-
men werden in der Reihenfolge angegeben, in der Sie immer tiefer in sie 'hin-
eintauchen'. Zur Trennung der Namen dient wieder der Schrבñgstrich.

* Am Ende eines Pfadnamens sollte immer ein Schrבñgstrich stehen (ggf. fב¶gt
die Shell beim Einlesen des Pfades selbst einen an).

Um die Verwirrung etwas zu lindern, hier ein Beispiel. Betrachten wir folgende
Directory−Struktur:

Angenommen, Sie wollen einen Pfad ins 'DEF'−Verzeichnis konstruieren (etwa
fב¶r die DEFPATHΓêÆListe in der BatchΓêÆDatei). Die ausfב¶hrlichste Angabe wבñre
"A:ב¶MODULAב¶LIBRARYב¶DEFב¶". Das funktioniert natב¶rlich nur, solange die
Diskette in Laufwerk A bleibt... Aber Sie wissen ja, daבƒ gerade die Shell
gestartet worden ist − also wird sicher das richtige Laufwerk gerade aktiv
sein. Daher genב¶gt die Angabe "ב¶MODULAב¶LIBRARYב¶DEFב¶".

Beide oben genannten Pfade beginnen im Wurzelverzeichnis. Wenn der
MODULA−Ordner in einen anderen Ordner hineinkopiert wird (oder wenn Sie
LIBRARY und SHELL direkt ins Wurzelverzeichnis legen), schicken Sie den
Rechner auf den Holzweg. Noch flexibler ist es daher, den Pfad relativ zum
aktiven Verzeichnis (SHELL, nehmen wir an) anzugeben! ..ב¶LIBRARYב¶DEFב¶
tut's, solange der LIBRARY−Ordner neben dem SHELL−Ordner in einem
ב¶bergeordneten Verzeichnis steht.

Umgang mit mehreren Projekten

Unter einem Projekt bei Megamax Modula−2 verstehen wir die Arbeit an einem
Programmpaket, das mehrere Module umfaבƒt und das seine eigene, individuelle
Umgebung hat.

Ein Beispiel: Nehmen wir an, Sie arbeiten abwechselnd an zwei Programmen,
das eine sei ein kleines TerminalΓêÆProgramm (zur DatenΓêÆKommunikation ב¶ber
Telefon), das andere ein Grafikprogramm zur Darstellung von physikalischen
Vorgבñngen. Nun bietet es sich an, die jeweils projektΓêÆspezifischen Dateien in
getrennten Ordner zu sammeln. Denken wir uns, Sie hבñtten zwei Ordner auf
Ihrer Harddisk (ja, sowas braucht man heutzutage), je einen fב¶r jedes
Programmpaket, in denen die jeweiligen Quelltext−Dateien abgelegt werden
sollen.

Da die beiden Programme vielleicht auch verschiedene Optionen (StackΓêÆGrבÀבƒe,
TreiberΓêÆModule usw.) benבÀtigen, sollten Sie sich dafב¶r je eine ProjektΓêÆDatei
anlegen. Diese Projekt−Dateien sind praktisch die Parameter−Dateien mit den
Endungen M2P. Wenn Sie alles richtig installiert haben, kבÀnnen Sie durch
einfache Aktionen zwischen Ihren beiden Projekten hin− und herwechseln und
finden bei beiden die individuellen Einstellungen und Arbeitsdateien vor.

Kommen wir also zum Erstellen einer Projekt−Datei. Zuerst erstellen Sie eine
BatchΓêÆDatei, die die gewב¶nschten Suchpfade enthבñlt. Nehmen Sie am besten
Ihre StandardΓêÆBatchΓêÆDatei MM2SHELL.M2B und verבñndern Sie die Pfadlisten
darin, so daבƒ die zusבñtzlichen Ordner fב¶r das jeweilige Projekt berב¶cksichtigt
werden. Am besten ist es, diese Pfade immer als erstes in die Listen zu
schreiben, damit sie Vorrang vor den restlichen haben. Speichern Sie die
Batch−Datei dann unter einem anderen Namen wieder ab.

Daraufhin tragen Sie den Namen hinter der Batch−Datei in den Shell−
Parametern ein. Dann vergeben Sie auch einen neuen Namen fב¶r die dortige
ParameterΓêÆDatei. Nun kבÀnnen Sie Ihr DiskΓêÆVerzeichnis des ProjektΓêÆOrdners
בÀffnen, die verwendeten Quelltexte als Arbeitsdateien eintragen und sonstige
Parameter einstellen, beispielsweise die StackΓêÆGrבÀבƒe oder, wenn das feste
Linken des Programms בÀfter benבÀtigt wird, auch die LinkerΓêÆOptionen
(verwendete Konfigurationsmodule usw.).

Sehr nב¶tzlich ist auch das Erzeugen einer MakeΓêÆDatei zum Hauptmodul des
Projekts (siehe Kapitel 2.7 zum Erstellen einer Make−Datei), die dann als
Default−Make in den Umgebungsinformationen eingetragen wird.

Sind alle Einstellungen vorgenommen, kann durch Drב¶cken von ControlΓêÆX, der
Anwahl des Menב¶punkts Parameter sichern oder einfach durch Verlassen der
Shell mit Parameter−Sicherung die vorher als Parameter−Datei eingegebene
Projekt−Datei gespeichert werden. Wenn Sie dann die Shell neu aufrufen,

Sie kבÀnnen sogar schon beim Start der Shell dafב¶r sorgen, daבƒ statt der
Standard−Parameter−Datei MM2SHELL.M2P eine andere verwendet wird: Dazu
mב¶ssen Sie die Shell unter dem GEMΓêÆDesktop fב¶r Dateien der Endung M2P
anmelden. Dann genב¶gt ein Doppelklick auf die ProjektΓêÆDatei, um die Shell zu
starten und das Projekt sofort vor sich zu haben. Um dies zu erreichen,
klicken Sie im GEM−Desktop die Shell MM2SHELL.PRG einfach (also nicht
starten!) an. Dann wבñhlen Sie in der Menב¶zeile Extras/Anwendung anmelden.
Dort geben Sie dann als geforderte Endung "M2P" ein und klicken auf
installieren. Zuletzt wבñhlen Sie Arbeit sichern an. Daraufhin kבÀnnen Sie nun
auf jede M2PΓêÆDatei doppelt klicken, um die Shell damit zu starten. (Bei בñlteren
TOSΓêÆVersionen mב¶ssen Sie aber darauf achten, daבƒ sich die ProjektΓêÆDateien
im Verzeichnis der Shell befinden, da diese sonst nicht gefunden wird.
Probieren Sie dies ggf. aus.)

Fehlermeldungen der Shell

Beim Programmieren kann erfahrungsgemבñבƒ einiges schiefgehen. Im Megamax
Modula−System gibt es vier Kategorien von Fehlermeldungen, die in solchen
Fבñllen erscheinen kבÀnnen.

* Ladefehler kבÀnnen auftreten, wenn ein Modul ausgefב¶hrt werden soll und nicht
alle benבÀtigten Module zur Verfב¶gung stehen. Die Fehlermeldungen beginnen
mit 'א½Modulnameא† konnte nicht ausgefב¶hrt werden', gefolgt von einer Beschreibung
des Problems. Diese Meldungen werden vom Loader erzeugt; Erlבñuterungen
finden Sie im Kapitel 5.

* Laufzeitfehler treten bei der Ausfב¶hrung fehlerhafter Anwenderprogramme
auf. Die Fehlerbeschreibung, der Modul− und der Prozedurname werden ange-
zeigt. Sie kבÀnnen sich entscheiden zwischen

Back/ Forward:

erlauben die Suche nach der Fehlerposition im Text (siehe 2.5);

Exit

verlבñבƒt die Fehlersuche und bietet drei weitere MבÀglichkeiten:

Cont

setzt das Programm fort. Bei manchen fatalen Fehlern ist eine sinnvolle
Fortsetzung nicht mבÀglich, und diese Option wird nicht angeboten.

Quit

bricht das Programm ab und kehrt zurב¶ck zur Shell.

Edit

lבñבƒt die durch Forward/ Back bestimmte Fehlerstelle suchen und im Editor
anzeigen, sofern der Quelltext des Moduls vorhanden ist. (siehe 2.5)

Eine kommentierte Liste der Fehlermeldungen steht im Anhang A.2.

* ב£bersetzungsfehler entstehen natב¶rlich beim Compilieren. Eine Liste der
Fehlermeldungen enthבñlt der Anhang A.1; wie Sie auf ב£bersetzungsfehler
reagieren kבÀnnen, beschreibt Kapitel 2.4.

* Bedienungsfehler in der Shell. So kommen Meldungen, wenn Sie mehr als
sieben Fenster בÀffnen, mehr als zehn Arbeitsdateien anfordern, mehr
Programme laden wollen, als freier Speicher zur Verfב¶gung steht, usw. Die
Meldungen sind alle selbsterklבñrend.

2.3 Editor

Einfב¶hrung

Als Teil des Megamax Modula−Systems haben Sie auch einen eigenen Editor
erhalten (genau genommen sogar zwei!). Er dient zur Eingabe (und Korrektur)
der Programmtexte. Die Texte werden als Standard−ASCII−Dateien (direkt
lesbare Textdateien) abgelegt und dem Compiler ב¶bergeben.

Der Editor ist speziell zum Schreiben von Programmtexten konzipiert worden.
Ihre Briefe werden Sie vielleicht auch weiterhin mit einer speziellen
Textverarbeitung schreiben wollen; zum Programmieren bietet Ihnen der
MegamaxΓêÆ Editor aber eine Reihe nב¶tzlicher Sonderfunktionen bei ב¶ber-
sichtlicher Bedienung.

Wahl des Editors

Prinzipiell kבÀnnen Sie jeden Editor verwenden, der normale Textdateien erzeugt
− die optimale Zusammenarbeit mit Shell und Compiler des Modula−Systems
erlauben allerdings nur die beiden mitgelieferten Editoren. (Die Zusammenarbeit
der Programme wird durch die Shell organisiert. Da Sie diese im Quelltext
erhalten, kבÀnnen Sie auch eine Anpassung fב¶r Ihren Lieblingseditor vornehmen,
wenn Sie sich nicht umstellen mבÀchten ΓêÆ die wichtigste בänderung dב¶rfte die
ב£bergabe der Fehlerposition und ΓêÆmeldung betreffen.)

Unser StandardΓêÆEditor heiבƒt GME. Unter anderem erlaubt er, mehrere Texte
im Speicher zu bearbeiten, bietet jedoch bisher noch keine echten GEM−
Fenster, statt dessen werden die Texte auf Befehl abwechselnd auf dem
Bildschirm angezeigt. Die Bedienung ist dem Konzept des legendבñren Editors
Word−Star nachempfunden. Der GME ist einfach zu bedienen, vor allem wegen
seiner GEMΓêÆMenב¶leiste, deswegen empfehlen wir den ProgrammierΓêÆEinsteigern
diesen Editor zur Benutzung.

Alternativ bieten wir einen kompakteren und schnelleren Editor, der allerdings
mehr EingewבÀhnung verlangt: Der GepardΓêÆEditor (GEP ED). Auch er arbeitet _
optimal mit dem Entwicklungssystem zusammen. Er ist, wie der GME, in
Modula geschrieben, hat jedoch einige deutliche Optimerungen in Assembler
erfahren. Er belegt nur ca. 50KByte (GME: 150) des Speichers in der Shell
und ist deshalb bei knappem Speicher dem GME vorzuziehen.

Der GME wurde aus einem Universaleditor entwickelt, der auch zur Text-
verarbeitung geeignet war. Demgegenב¶ber ist der GepardΓêÆEditor speziell auf
das Programmentwickeln zugeschnitten und bietet keine GEMΓêÆOberflבñche ΓêÆ fב¶r
die Veteranen: Sein Konzept ist dem des UCSD−Programmeditors nach-
empfunden, nur ist er wesentlich schneller. Der Editor ist gewבÀhnungsbedב¶rftig,
aber unglaublich effektiv fב¶r Vielprogrammierer ΓêÆ wir MegamaxΓêÆEntwickler
verwenden ihn alle!

Beide Editoren erlauben es, den Programmtext im Speicher zu ב¶bersetzen,
ohne daבƒ der Text abgespeichert und der Editor verlassen zu werden braucht.
Dies verkב¶rzt die TurnΓêÆAroundΓêÆZeit (Zeit zwischen Editieren, ב£bersetzen und
Starten) deutlich.

Auch Tempus (von CCD) lבñבƒt sich sehr bequem als Editor verwenden. Einzig
die Fehleranzeige vom Compiler beherrscht er nicht − die Shell sieht aber eine
Option vor, so daבƒ Compilerfehler vor dem EditorΓêÆStart angezeigt werden.
Nach einer Bestבñtigung mit der ReturnΓêÆTaste wird der Editor gestartet und er
zeigt dann die Fehlerposition im geladenen Text an.

Bei Tempus kבÀnnen Sie ein Programm zwar nicht im Speicher direkt ב¶berset-
zen lassen, aber der Komfort kommt auch hier nicht zu kurz: Drב¶cken Sie
ControlΓêÆ1 (Sie mב¶ssen die Eins vom rechten Ziffernblock verwenden!), wird der
Text automatisch gespeichert, Tempus verlassen und automatisch der Compiler
gestartet, der dann den Programmtext ב¶bersetzt, den Sie von der Shell an den
Editor beim Aufruf ב¶bergeben hatten (und das ist in der Regel auch der, den
Sie dann mit ControlΓêÆ1 zum ב£bersetzen abspeichern lassen). ControlΓêÆ2 teilt
der Shell mit, daבƒ sie nach erfolgreicher ב£bersetzung dieses Modul starten
soll, ControlΓêÆ3 bewirkt nicht das ב£bersetzen des geladenen Programms,
sondern aktiviert das DefaultΓêÆMake, das in der Shell auch ב¶ber die Taste M
auslבÀsbar ist. Schlieבƒlich lבñבƒt ControlΓêÆ4 nach dem ΓêÆ erfolgreichen ΓêÆ MakeΓêÆLauf
das Programm wiederum gleich starten.

Leider lassen sich die Versionen 2.00 bis 2.04 von Tempus nicht resident in
der Shell laden: Beim wiederholten Start in der Shell wב¶rde er nicht mehr
funktionieren. Wenden Sie sich in diesem Falle ggf. an CCD, um eine neuere,
korrigierte Version zu erhalten. Alle anderen Versionen lassen sich resident
laden, aber benבÀtigen sehr (wirklich sehr) viel mehr Speicher als die Programm-
datei lang ist. Auch hier sollten Sie sich nicht verwirren lassen ΓêÆ das muבƒ so
sein!

Vorbereitungen und Parameter fב¶r den Editor

Bevor der Editor Ihres Ver-
trauens von der Shell richtig
aufgerufen werden kann,
muבƒ zumindest dessen
Dateiname bekannt gemacht
werden. Unter dem
Menב¶punkt Parameter/Editor
sind alle Optionen fב¶r den
Editor erreichbar. Hier kann
hinter Editor: dessen Name
eingetragen werden. Soll der
GME verwendet werden, kann dieser Name, wie im Bild zu sehen, verwendet
werden. Fב¶r den GepardΓêÆEditor ist GEP ED einzutragen, bei allen anderen _
Editoren ist ihr vollstבñndiger Dateiname inclusive seiner Endung zu verwenden
(Tempus: TEMPUS.PRG). Bei Editoren, die andere Dateien nachladen mב¶ssen,
wie eine RSCΓêÆDatei oder Konfigurationen, muבƒ auבƒerdem deren Pfadname mit
angegeben werden. Haben Sie beispielsweise einen Editor namens EDIT.PRG,
der im Ordner C:ב¶TEXTE mitsamt seiner ResourceΓêÆDatei EDIT.RSC steht, ist
C:ב¶TEXTEב¶EDIT.PRG einzutragen.

Die mitgelieferten Editoren kבÀnnen, da sie mit dem MegamaxΓêÆModulaΓêÆSystem
erstellt wurden, auf die Pfadlisten in ShellMsg zugreifen, speziell auf die
Suchpfade fב¶r die Quelltexte (ב¶ber SourcePath in Batch zu bestimmen). So
brauchen Sie beim Laden eines Textes diesen nicht erst in den vielen
Verzeichnissen zu suchen, statt dessen sucht der Editor die Datei selbstבñndig
auf den Source−Pfaden. Wird ein anderer Editor verwendet, kann die Shell das
ב¶bernehmen, wenn sie beim EditorΓêÆAufruf den Dateinamen ב¶bergibt. Dazu muבƒ
nur die Option Shell durchsucht SourceΓêÆPfade fב¶r den Editor aktiviert sein.
Dann reicht es beispielsweise, in der Shell mit Control−P den Namen eines
Textes ohne dessen Pfad einzutippen und dann den Editor mit Control−E zu
starten.

Wenn Editoren es nicht vermבÀgen, eine Fehlermeldung beim Aufruf ב¶bergeben
zu bekommen, um sie dann anzuzeigen, muבƒ die Shell dies erledigen. Dazu
dient der Schalter Shell zeigt Compiler−Fehler vor Editor−Aufruf an. Ist er
eingeschaltet, zeigt die Shell nach einem Compiler−Fehler diesen an, und erst
nach Drב¶cken der ReturnΓêÆTaste wird der Editor gestartet. Vertrבñgt der Editor
die Fehlermeldung nicht (z.B. TEMPUS), muבƒ auבƒerdem weiter unten bei
Argumentzeile der Schalter Fehlermeldung deaktiviert sein.

Die Temporבñren Dateien dienen zur ב£bergabe von Informationen an den Editor
und zurב¶ck an die Shell. Der einzige uns bekannte Editor, der diese Art der
Parameterב¶bergabe unterstב¶tzt ist der EmacsΓêÆEditor. Der ist programmierbar,
und so hat ein Megamax−Anwender ein Programm erstellt, das es erlaubt, von
der Shell Textname, Fehlermeldung und −position anzunehmen und beim

In der Argumentzeile an den Editor kבÀnnen Textname, Fehlermeldung und
−position vom Compiler bzw. von der Shell beim Aufruf an den Editor
ב¶bergeben werden. Die MegamaxΓêÆEditoren erlauben alle ב£bergaben. TEMPUS
beispielsweise erlaubt die Angabe der Cursorposition, jedoch nicht die der
Meldung, sodaבƒ diese dann zu deaktivieren wבñre.

Wollen Sie einen Editor verwenden, der noch andere Bedingungen an seine
Benutzung stellt, z.B. daבƒ bei der Fehlerposition die Werte fב¶r Spalte und Zeile
zu vertauschen wבñren, kבÀnnen Sie dies selbst an der ShellΓêÆSource vornehmen:
Der Editor−Aufruf wird in der Funktion hdedit vorbereitet. Die Fehlermeldung
vom Compiler wird bei einem der Aufrufe von hdedit aufbereitet. Nach der
Anpassung muבƒ die Shell neu ב¶bersetzt und dann gelinkt werden. Zum Linken
bietet sich der Batch LINKSHEL.M2B an, der dazu alle erforderlichen
Parameter einstellt.

Aufruf des Editors

Den Editor kבÀnnen Sie auf drei Wegen starten:

* Aus der Shell: Klicken Sie das Editor−Symbol auf der Ar-
beitsflבñche an (Editieren der Arbeitsdatei) oder legen Sie
einen Dateinamen auf dem Editor−Symbol ab. Wollen Sie ein
neues Dokument beginnen, so geben Sie zunבñchst einen leeren Namen an.

* Nach ב£bersetzungsfehlern: Je nach Wahl der EditorΓêÆOptionen ruft die
Shell den Editor sofort auf oder bietet Ihnen erst den Aufruf des Editors
an. Wenn Sie dann diese Option wבñhlen, wird automatisch der fehlerhafte
Text geladen, der Cursor wird an der Fehlerstelle positioniert, und in der
Kopfzeile des Editors erscheint eine Fehlerbeschreibung.

* Nach Laufzeit−Fehlern: Wenn Ihnen der Text des fehler-
haften Programms zur Verfב¶gung steht, kבÀnnen Sie nach
Laufzeitfehlern die ScannerΓêÆFunktion wבñhlen. Der Compiler
ermittelt die Textposition, an der der Fehler auftrat, und zeigt Ihnen,
genau wie bei ב£bersetzungsfehlern, die Fehlerstelle mit Beschreibung im
Editor.

Bedienung des Editors

Die Bedienung der beiden Editoren wird in separaten Anleitungen beschrieben,
die Sie im Anhang finden.

2.4 Compiler

Hier erlבñutern wir die eigentliche Handhabung des ModulaΓêÆCompilers. Wenn Sie
sich ב¶ber den ב¶bersetzten Sprachumfang oder die CompilerΓêÆOptionen in Quell-
texten informieren wollen, lesen Sie bitte Kapitel 3 dieses Handbuchs.

Aufruf des Compilers

Der Compiler wird aus der Shell gestartet, indem Sie

* eine Textdatei aus einem Disk−Fenster mit der Maus greifen
und auf das Compiler−Symbol schieben;

* das CompilerΓêÆSymbol doppelt anklicken, um die Arbeitsdatei zu ב¶bersetzen;

* die Taste C drב¶cken, um die Arbeitsdatei zu ב¶bersetzen (o. CtrlΓêÆC fב¶r die
aktuelle Datei).

Der Pfad der Quelldatei muבƒ nicht angegeben werden ΓêÆ der Compiler sucht die
Datei automatisch auf den Source−Pfaden (SourcePath in der Batch−Datei).

Falls die angegebene Textdatei vom Compiler nicht gelesen werden kann, fragt
der Compiler Sie nochmals nach einem Datei−Namen. Durch eine Leereingabe
kבÀnnen Sie den Compiler dann auch wieder verlassen. Wenn der Text gefunden
wird, beginnt der Compiler die ב£bersetzung.

Die Endungen (Suffix, Extension) der Quelldatei−Namen sind beliebig. Bei
Megamax Modula verwenden wir in der Regel

.M fב¶r HauptΓêÆModulΓêÆQuellen (Bsp: MSHELL.M, TEXTDEMO.M),

.I fב¶r ImplementationsmodulΓêÆQuellen (Bsp: DEBUG.I, MOSCONFI.I),

.D fב¶r DefinitionsmodulΓêÆQuellen (Bsp: INOUT.D, DEBUG.D).

BenבÀtigte Definitionsmodule werden automatisch gesucht. Als Name werden
dabei die ersten 8 Zeichen des Modulnamens (also nicht des Dateinamens!),
gefolgt von der Extension .DEF, angenommen. Diese Dateien werden auf allen
Pfaden gesucht, die Sie in der Batch−Datei als DefPath angegeben haben
(siehe Kapitel 2.2 − Shell).

Die erzeugten Dateien

Den Namen der erzeugten Code−Datei bestimmt der Compiler ebenfalls
automatisch. Wieder werden die ersten 8 Zeichen des Modulnamens verwendet;
die Extension lautet

.MOD fב¶r ProgrammΓêÆModulΓêÆCodes,

.DEF fב¶r DefinitionsΓêÆCodes und

.IMP fב¶r ImplementationsΓêÆCodes.

Andere Endungen kבÀnnen Sie ב¶ber die Compileroption $E einstellen (siehe
Kapitel 3.3, Compileroptionen), z.B. MOS oder MTP (בñquivalent zu TOS und
TTP bei gelinkten Programmen, wבñhrend MOD wie PRG behandelt wird).

Die StandardΓêÆEndungen kבÀnnen Sie aber auch verבñndern ΓêÆ nבñheres dazu in
Kapitel 5.

Der Ausgabepfad fב¶r das ב¶bersetzte Modul wird normalerweise ב¶ber die
Suchpfade bestimmt, die in der Batch−Datei stehen, welche beim Start der
Shell ausgefב¶hrt wird: Der Compiler wבñhlt jeweils den ersten Pfad aus der
Pfadliste fב¶r DefinitionsΓêÆ, ImplementationsΓêÆ oder ProgrammΓêÆModule. ב£ber die
BatchΓêÆAnweisungen DEFOUT, IMPOUT und MODOUT kבÀnnen aber auch
individuelle Ausgabepfade eingestellt werden − sind dahinter keine Pfade
angegeben, wird die Code−Datei in das Verzeichnis geschrieben, aus dem die
jeweilige Quell−Datei stammt.

Ist allerdings ein Pfad ב¶ber die BatchΓêÆAnweisung MainOutputPath oder ב¶ber die
Compiler−Parameter in der Shell (siehe folgenden Abschnitt Compiler−
Parameter) eingegeben, hat dieser Vorrang vor allen anderen Pfad−
Bestimmungen!

ב£bersetzungsfehler

Findet der Compiler in dem ב¶bersetzten Programmtext einen Fehler, bricht er
den ב£bersetzungsvorgang ab und meldet dies der Shell, die dann entweder den
Editor sofort aufruft oder erst ein Fenster בÀffnet, in dem sie Ihnen die
Fehlermeldung prבñsentiert und Sie vor die Wahl stellt, die Fehlerstelle im
Editor zu korrigieren oder die ב£bersetzung ganz abzubrechen.

Um als Fehlermeldung eine Beschreibung des Problems ausgeben zu kבÀnnen,
benבÀtigt der Compiler die Fehlerdatei. Sie heiבƒt normalerweise 'MODULA.ERR'
Fehlt diese Datei, dann wird nur eine Fehlernummer angezeigt, deren Bedeu-
tung Sie im Anhang A.1 des Handbuchs nachschlagen kבÀnnen. Dort finden Sie
zu vielen Fehlermeldungen auch zusבñtzliche Hinweise, die bei der Behebung des
Fehlers helfen kבÀnnen.

Compiler−Parameter

ב£ber die Anwahl Parameter/
Compiler im Menב¶ der Shell
kבÀnnen Sie die globalen Op-
tionen des Compilers ein-
stellen.

Ist Ausgabe der Kurzmel-
dungen mit einem Hבñkchen
versehen, werden die Namen
der importierten Module, der
ב¶bersetzten Prozeduren und
die Anzahl der ב¶bersetzten
Zeilen ausgegeben. Die gleiche Funktion kann in Programmtexten durch die
Compileroption $Q gesteuert werden (siehe 3.3, Compilerdirektiven; dort finden
Sie auch Tips zur Anwendung dieser Option).

Ausgabepfad: Soll ein ב¶bersetztes Modul nicht auf dem Pfad gespeichert
werden, der in der StartΓêÆBatchΓêÆDatei fב¶r die entsprechende Modulart
angegeben ist, kann hier ein anderer Pfad eingetragen werden, der dann auf
alle erzeugten Modularten wirkt. Dieser Pfad kann auch mit dem Batch−Befehl
MAINOUTPUTPATH bestimmt werden. Siehe auch Kapitel 2.2 zu den Batch−
Anweisungen.

Die Direktiven erlauben die Beeinflussung des Verhaltens des Compilers beim
ב£bersetzen. Beispielsweise kבÀnnen Sie bestimmen, ob zusבñtzlicher Code fב¶r
Laufzeitprב¶fungen erzeugt werden soll. Nבñheres zur Funktion den Direktiven in
Kapitel 3.4. Statt die Direktiven in den Quelltext einzufב¶gen, kבÀnnen sie hier in
der Eingabezeile voreingestellt werden. Jeder DirektivenΓêÆBuchstabe muבƒ dabei
mit einem Plus− bzw. Minuszeichen eingeleitet werden, mehrere Direktiven
werden durch Leerzeichen getrennt. Im Bild sehen Sie beispielsweise die
Direktiven $Z+ und $R−.

In der Library MM2DEF.M2L sind (fast) alle ב¶bersetzten Definitionsdateien der
MegamaxΓêÆBibliotheken zusammengefaבƒt. Dies spart Platz auf der Disk und
beschleunigt den ב£bersetzungsvorgang. Normalerweise sollte deshalb der Name
der Datei (mit Pfad) unter Bibliothek eingetragen sein. Ist eine Bibliothek
angegeben, haben die darin enthaltenen DEF−Dateien immer Vorrang vor den
separaten Definitions−Modulen in den Ordnern, die in der Pfadliste DefPath im
Batch angegeben werden kבÀnnen! Unter Umstבñnden kann dies nicht erwב¶nscht
sein ΓêÆ dann braucht einfach nur der Bibliotheksname gelבÀscht zu werden. Zur
Kontrolle, woher ein Definitionsmodul beim ב£bersetzen geladen wird, kann die
Anzeige der Kurzinformationen aktiviert werden.

Die Textdatei mit den Fehlermeldungen fב¶r den Compiler wird in Fehlerdatei
eingetragen, ggf. mitsamt dem Pfad.

Protokoll: Auf Wunsch erzeugt der Compiler ein ב£bersetzungsprotokoll. Die
Ausgabebreite (Anzahl Spalten) und der Name der Protokolldatei (mit
Pfadangabe) kבÀnnen eingestellt werden. Der Inhalt der Protokolldatei wird in
einem speziellen Abschnitt auf einer der folgenden Seiten beschrieben.

Definitions−Codes: Bibliothek und Komprimierung

Die ב¶bersetzten Definitionsmodule werden vom Compiler praktisch immer
benבÀtigt, darב¶ber hinaus stבÀren sie nur, weil sie sonst in keiner Weise
Verwendung finden.

Deshalb haben wir es ermבÀglicht, daבƒ die DefinitionsΓêÆCodes alle in einer Datei
zusammengefaבƒt werden kבÀnnen. Damit ist das Weiterkopieren einfacher, es
werden nicht unzבñhlige VerzeichnisΓêÆEintrבñge auf der Disk verschwendet, und
der Compiler kann sogar schneller darauf zugreifen.

Diese Datei, in der die DefinitionsΓêÆCodes zusammengefaבƒt sind, nennen wir
BibliotheksΓêÆDatei oder auch Library (das ist engl. und heiבƒt in etwa das selbe).
Das Lesen der einzelnen Definitionen aus der Library ist fב¶r den Compiler sehr
einfach. Demgegenב¶ber ist es aber aufwendig, stבñndig neue Dateien darin
einzufב¶gen oder auszutauschen. Darum bietet es sich an, nur solche
Definitionen in die Library einzufב¶gen, die keines stבñndigen Erneuerns bedב¶rfen.
Die trifft vor allem auf die beim Megamax−System mitgelieferten MOS−Module
zu ΓêÆ die בñndern hבÀchstens wir, und das kבÀnnen wir dann gerade noch selbst
bewבñltigen. Sie selbst kבÀnnen also auch DefinitionsΓêÆCodes hinzufב¶gen, nur
sollten Sie sich dieses Aspekts bewuבƒt sein ΓêÆ wird die Definition verבñndert,
muבƒ sie in der verwendeten Library aktualisiert werden, denn der Compiler
kann neu ב¶bersetzte Definitionen nicht automatisch in der Library ablegen, und
die Library hat immer Vorrang vor den Definitions−Codes in den normalen
Verzeichnissen.

Die DefinitionsΓêÆCodes in die LibraryΓêÆDatei einzufב¶gen, hat also zwei Vorteile:
Erstens sind sie darin hב¶bsch und unauffבñllig verpackt, zweitens kann der
Compiler schneller darauf zugreifen, als dies bei den Einzeldateien mבÀglich ist.
Natב¶rlich mב¶ssen Sie nicht alle Ihre DefinitionsΓêÆCodes in die Library quetschen,
denn der Compiler kann sie selbstverstבñndlich auch finden, wenn sie ganz
normal einzeln in den Verzeichnissen vorliegen: Der Compiler sucht beim
Importieren zuerst in der Library, dann in der DefPaths−Liste, welche im
Batch (meist MM2SHELL.M2B) bestimmt werden kann.

Mit dem UtilityΓêÆProgramm LibManager (ggf. erst ב¶bersetzen!) kבÀnnen Sie die
Library bearbeiten. Sie kבÀnnen sich deren Inhalt ansehen sowie Dateien
einfב¶gen, herauskopieren oder lבÀschen. Das Programm ist menב¶gefב¶hrt und
daher (hoffentlich) selbsterklבñrend.

Eine weitere Optimierung besteht darin, die Definitionen zu komprimieren. Die
Codes in der mitgelieferten Library MM2DEF.M2L sind bereits komprimiert.
Dadurch ergibt sich eine Platzersparnis von ca. 55%. Der Compiler erkennt
beim Importieren automatisch, ob die Definitions−Codes komprimiert sind, und
expandiert sie dann selbststבñndig.

Jeder Definitions−Code kann komprimiert werden − der Compiler macht keinen
Unterschied, ob die Datei in der Library oder als Einzeldatei vorliegt.

Allerdings hat die Kodierung auch einen Nachteil: Durch das notwendige
Expandieren dauert die Bearbeitung solcher Importe lבñnger. Sind Sie stolzer
Besitzer einer Hard−Disk, sollten Sie daher die Dateien der Library alle
dekomprimieren, damit der Compiler damit keine unnבÀtige Zeit mehr verbringen
muבƒ.

Dekomprimieren der Dateien in der Library

Mit den Programmen Encode und Decode (UTILITYΓêÆOrdner) kבÀnnen die Dateien
(eigentlich jede beliebige Datei) gepackt und wieder entpackt werden. Beide
Programme sind sehr einfach anzuwenden: Beim Start wird nach einer Datei-
angabe gefragt. Geben Sie dann entweder die einzelne Datei an oder ver-
wenden Sie Wildcards (z.B. D:ב¶MM2ב¶DEFב¶*.*), um mehrere Dateien in einem
Verzeichnis auf einmal anzusprechen. Wundern Sie sich nicht, daבƒ das Kompri-
mieren relativ lange dauert − wir haben bisher nur die Dekomprimierungs−
Algorithmen zeitlich optimiert, weil dies erstmal am wichtigsten war.

Wollen Sie nun die gepackte Library MM2DEF.M2L dekomprimieren, kבÀnnen Sie
nicht einfach die ganze Datei auf einmal entpacken. Statt dessen mב¶ssen Sie
erst mit dem LibManager alle Dateien herauskopieren, dann diese Einzeldateien
alle mit Decode dekomprimieren und am Ende alle Dateien wieder zu einer
neuen Library zusammenfב¶gen (wiederum durch Verwendung von LibManager).

Protokoll

Ein ב£bersetzungsprotokoll kann bei der Suche nach Laufzeitfehlern oder auch
beim Verstehen eines fremden Programms nב¶tzlich sein, da es neben dem
Quelltext noch zusבñtzliche Angaben enthבñlt.

Ein typisches Compilerprotokoll sieht z. B. so aus:

Die erste Spalte enthבñlt durchlaufende Zeilennummern fב¶r den Text. Dann folgt
ein Zבñhler fב¶r die Schachtelungstiefe von Prozeduren und Modulen, dessen
Nutzen Sie bei etwas komplizierteren Programmen als dem obigen Beispiel
erkennen werden.

Die dritte Spalte gibt die Adresse des Zeilenanfangs im Codemodul an. Diese
Angabe ist immer relativ zum Modulanfang zu verstehen. Die gleiche relative
Adresse meldet Ihnen das System auch, wenn ein Laufzeitfehler auftritt − im
Protokoll kבÀnnen Sie so auf einen Blick die Fehlerzeile orten. (Eine andere
MבÀglichkeit der Fehlersuche bietet allerdings der Scanner ΓêÆ siehe Kapitel 2.5
'Debugger'.) Wenn Deklarationszeilen ב¶bersetzt werden, erscheint statt einer
Adresse ein "D" im Protokoll.

Durch das Einfב¶gen der zusבñtzlichen Spalten in das Protokoll passen die fol-
genden Zeilen des Programmtextes oft nicht mehr komplett auf eine Zeile von
80 Zeichen. Der Compiler bricht dann im Protokoll den Rest der Zeile um.
Wenn Sie allerdings das Protokoll (z.B. auf einem Drucker) mit mehr als 80
Zeichen Breite ausgeben wollen, kבÀnnen Sie das Format im ParameterΓêÆMenב¶
auf andere Zeilenlבñngen einstellen.

Am Schluבƒ der Protokolldatei folgt eine Liste der globalen Variablen mit den
jeweiligen relativen Adressen (die erste Variable liegt auf der rel. Adresse 0).

Die Startadressen der globalen Variablen und der Module kבÀnnen Sie durch
verschiedene Funktionen in den Modulen Loader und ModCtrl ermitteln
(Beispielprogramme in Ordnern DEMO & UTILITY: GPA, ModList und TraceMod).
In der Shell werden durch Alternate−R jedes vorhandene Modul sowie die
Startadressen und Lבñngen des Codes angezeigt, ebenso wie mit ModList.

2.5 Debugger

Megamax Modula unterstב¶tzt Sie bei der Fehlersuche durch spezielle
DebuggingΓêÆFunktionen (die ב£bersetzung "Entwanzen" kennen Sie vermutlich
schon). Ein spezielles Debugger−Programm werden Sie allerdings vergeblich
suchen ΓêÆ beim Suchen helfen Ihnen der Compiler persבÀnlich und das Imple-
mentationsΓêÆModul Debug. Diese DebugΓêÆFunktionen ersparen Ihnen die ב¶bliche
Fehlersuche bei compilierten Sprachen durch Einfב¶gen diverser Testausgaben in
den Programmtext; sie helfen auch beim Aufspב¶ren vertrackter Probleme.

Fב¶r "harmlosere" Fבñlle bietet Megamax Modula eine weitere Hilfe bei der
Fehlersuche: das Auffinden der Programmstelle im Test, an der ein
Laufzeitfehler auftrat. Diese Scan−Funktion ist im letzten Abschnitt dieses
Kapitels beschrieben.

ב£bersetzen im DebugΓêÆModus

Wollen Sie ein Programm 'debuggen', fב¶gen Sie bitte als erstes ein 'IMPORT
Debug' in die Importliste ein (falls das Programm im TOSΓêÆModus lבñuft, also die
Endung MOS oder MTP hat, importieren Sie besser TOSDebug). Das Modul
Debug enthבñlt die Laufzeitfunktionen, die bei der Fehlersuche benבÀtigt werden,
und muבƒ daher im RAM zur Verfב¶gung stehen.

Mit der Compiler−Option (*$ D+ *) im Programmtext schalten Sie den Compiler
in den DebugΓêÆModus um. Fב¶r alle Programmzeilen, die in diesem Modus
ב¶bersetzt werden, erzeugt der Compiler zusבñtzlichen Code, so daבƒ diese Zeilen
schrittweise, mit Ausgabe des Programmtextes und der berechneten
Ausdrב¶cke, ausgefב¶hrt werden kבÀnnen.

Natב¶rlich braucht dieser zusבñtzliche Code auch zusבñtzlichen Platz im
ב¶bersetzten Modul. Auבƒerdem ist die Ausfב¶hrung von Programmen im DebugΓêÆ
Modus wesentlich langsamer als im Normalfall − das 'Debuggen' einer 5000
mal durchlaufenen Schleife beschert Ihnen nicht nur jede Menge Bildschirm-
ausgaben sondern auch eine ausgedehnte Kaffeepause.

Sie sollten daher die MבÀglichkeit nutzen, gezielt einzelne Programmteile
zwischen (*$ D+ *) und (*$ DΓêÆ *) einzuschlieבƒen und zu untersuchen. Oft ist es
sinnvoll, zunבñchst das Hauptprogramm zu ב¶berprב¶fen und herauszufinden,
welche Prozedur fehlerhaft ist. In einem weiteren Compilerlauf kann dann diese
Prozedur im DebugΓêÆModus ב¶bersetzt werden.

Ausfב¶hren im DebugΓêÆModus

Ein Programm, das im DebugΓêÆModus ב¶bersetzt wurde, enthבñlt zusבñtzliche
TRAPΓêÆAnweisungen, die das Modul 'Debug' abfבñngt. 'Debug' sorgt fב¶r die
Ausgabe der ausgefב¶hrten Zeilen und berechneten Ausdrב¶cke; zusבñtzlich
erlaubt das Modul die Beeinflussung der Ausfב¶hrung ב¶ber die Tastatur.

Die normale Anzeige jeder Programmzeile besteht aus der Textzeile des
Programms; darunter werden alle in dieser Zeile berechneten arithmetischen
Ausdrב¶cke ('Expressions' in der Syntaxbeschreibung) in der Reihenfolge ihrer
Berechnung ausgegeben. Die Reihenfolge dieser Ausgaben ist nicht immer
einfach zu ב¶berblicken und soll am folgenden Beispiel erlבñutert werden:

IF ORD(a) = b+ c THEN d:= e; f:= h+ (2 * g) END;

Nach dem IF steht laut Modula−Syntax eine 'Boolean Expression', die
ausgegeben wird. Bei der Berechnung dieses Ausdrucks wird jedoch eine
weitere 'Expression' ausgerechnet, nבñmlich das Argument der Funktion ORD ΓêÆ
dessen Wert erscheint also als erste Ausgabe. Der Wert b+ c wird dagegen
nicht angezeigt, denn links und rechts vom Gleichheitszeichen stehen
syntaktisch nur Simple Expressions.

Die im THENΓêÆTeil berechneten Ausdrב¶cke erscheinen natב¶rlich nur, wenn
dieser Zweig ausgefב¶hrt wird. Der erste Ausdruck ist der auf א½dא† zugewiesene
Wert, also א½eא†. Bei der Berechnung des Ausdrucks, der auf א½fא† zugewiesen
wird, ist wiederum ein zusבñtzlicher Ausdruck auszuwerten: In Klammern steht
laut Syntaxdiagramm wieder eine 'Expression'. Also wird erst der Wert א½2 * gא†
ausgegeben, dann א½h+ 2 * gא†.

Auבƒer 'Expressions' werden noch die Werte von Variablen angezeigt, die als
Parameter an Prozeduren ב¶bergeben werden.

Allgemeiner Tip: Wenn mehr (oder weniger) Werte ausgegeben werden, als Sie
erwarten, sehen Sie im Syntaxdiagramm nach, wo wirklich 'Expressions'
stehen. Um die Ausgabe eines Teilausdrucks zu erzwingen, ist es oft mבÀglich,
ihn in Klammern zu setzen − innerhalb der Klammern wird wieder eine
vollstבñndige Expression erwartet und ausgegeben.

Leertaste veranlaבƒt Ausfב¶hrung und Ausgabe der nבñchsten Zeile
oder schaltet von laufender Ausfב¶hrung auf Einzelschritt.

א½Returnא† schaltet von Einzelschritt auf laufende Ausfב¶hrung.

א½Hא† wבñhlt Ausgabe von Skalaren als Hexadezimalzahlen.

א½Dא† wבñhlt Ausgabe von Skalaren als Dezimalzahlen.

א½Sא† Eingabe einer Schrittweite: die eingegebene Anzahl Zeilen
wird ohne Ausgaben (schneller) ausgefב¶hrt.

א½Aא† aktiviert die Ausgabe wieder, wenn sie durch א½Sא†
unterdrב¶ckt wurde.

א½Lא† schaltet zusבñtzliche Ausgabe der Zeilenadresse zu jeder
Programmzeile ein/aus.

א½Rא† veranlaבƒt einmalige Ausgabe aller CPUΓêÆRegister.

Die gleichen Kontrollfunktionen kבÀnnen statt von der Tastatur auch vom
laufenden Programm aus umgeschaltet werden. Dazu kבÀnnen Steuervariablen
aus dem Modul 'Debug' importiert und verבñndert werden. Das erfordert zwar
einige zusבñtzliche Anweisungen im Programm, erleichtert aber manchmal die
gezielte Fehlersuche sehr − z.B. wenn die Debug−Ausgaben erst aktiviert
werden sollen, wenn eine Variable einen bestimmten Wert hat oder eine
Prozedur mit vorgegebenen Argumenten aufgerufen wurde. Die Funktion der
Steuervariablen im einzelnen:

Continous: BOOLEAN = "laufende Ausfב¶hrung ohne Warten"

Active: BOOLEAN = "folgende א½Stepא† Schritte ohne Anzeige ausfב¶hren"

Step: LONGCARD = Anzahl der Schritte, die ohne Anzeige auszu-
fב¶hren sind (zusבñtzlich muבƒ Active = FALSE sein)

LineAddr: BOOLEAN = "zu jeder Programmzeile Adresse ausgeben"

Hex: BOOLEAN = "Skalare als Hexadezimalzahlen ausgeben"

Der Scanner − Suchen der Fehlerposition

In vielen Fבñllen werden Sie das DebugΓêÆModul zur Fehlersuche
aber gar nicht benבÀtigen ΓêÆ es gibt noch eine einfache und oft
wesentlich schnellere MבÀglichkeit, Programmierfehlern auf die
Spur zu kommen. Oft genב¶gt es ja zu wissen, welche Stelle des Programms
(im Text) gerade ausgefב¶hrt wurde, als ein Laufzeitfehler auftrat. Dabei
unterstב¶tzt Sie der 'Scanner', den Sie auf der ShellΓêÆArbeitsflבñche als Lupe
abgebildet sehen.

Hinter dem Scanner verbirgt sich in Wirklichkeit wiederum der Compiler −
allerdings in einer Betriebsart, die keine Codedatei erzeugt, sondern nur
so lange 'ins Blaue' ב¶bersetzt, bis eine bestimmte Adresse im erzeugten
Codemodul erreicht ist. Dann stoppt der Scanner und ruft den Editor auf, um
die erreichte Textstelle zu zeigen.

Wenn ein Laufzeitfehler auftritt, ermittelt das Modula−System, in welchem
Modul und auf welcher relativen Adresse innerhalb des Moduls die Ausfב¶hrung
unterbrochen wurde. Sie kבÀnnen wבñhlen:

* Exit, um die angezeigte Fehlerposition im Programmtext zu suchen.

* Back, um statt der angezeigten Fehlerposition die Position des Aufrufers zu
sehen (s.u.);

* Frwd, um entsprechend wieder die Position des nבñchsttieferen Aufrufs zu
bekommen.

Nach Wahl von Exit haben Sie nochmals die MבÀglichkeit, durch Quit zur Shell
zurב¶ckzukehren oder durch Cont das Programm doch fortzusetzen. Durch Edit
schlieבƒlich starten Sie den Scanner, der Ihnen die gefundene Fehlerstelle dann
im Editor prבñsentiert.

Gelegentlich mב¶ssen Sie noch etwas mehr tun, um den Ursprung eines
Laufzeitfehlers zu finden: Unter Umstבñnden ruft das fehlerhafte Programm
eine Prozedur (evtl. in einem anderen Modul) mit falschen Parametern auf, und
erst dort wird der Fehler ausgelבÀst. Dann interessiert Sie natב¶rlich nicht die
Position in der Prozedur, sondern die des falschen Aufrufs. In diesem Fall
klicken Sie in der ScannerBox bitte nicht Exit, sondern Back an − eine neue
Scanner−Box zeigt Ihnen Modulnamen und Adresse des Aufrufers. Dieses
Rב¶ckverfolgen zum Aufrufer kבÀnnen Sie wiederholen, bis das 'verdבñchtige'
Modul erreicht ist. Sind Sie in der Aufrufer−Kette zu weit 'geklettert', dann
kבÀnnen Sie mit Frwd wieder tiefer steigen. Wenn Sie den eigentlichen
Verursacher des Fehlers gefunden haben, wבñhlen Sie Exit, und nach einem
Scannerlauf wird die Position in diesem Modul angezeigt.

Manuelles Starten des Scanners

Bei der oben beschriebenen Bedienung des Scanners ist das Scanner−Symbol
auf der Arbeitsflבñche noch gar nicht benutzt worden. In zwei Fבñllen kommt
dieses Symbol zur Anwendung:

* Wenn Sie nach einem Laufzeitfehler eine Adresse aus der Aufruferkette
ausgewבñhlt haben (durch 'Back' / 'Forward'), die sich nach dem Scannen nicht
als der eigentliche Verursacher des Fehlers herausstellt. In diesem Fall
mבÀchten Sie wahrscheinlich noch eine andere Adresse aus der Kette
untersuchen.

* Wenn nach einem fatalen Laufzeitfehler die Shell und der Scanner nicht
mehr funktionieren (etwa nach ב£berschreiben wichtiger Speicherbereiche). Die
Fehlerposition im Code sollten Sie in jedem Fall noch erfahren; nach einem
Neustart der Shell lבñבƒt sich die zugeordnete Textstelle dann durch einen
manuellen Scanner−Aufruf (mit Eingabe der Adresse von Hand) feststellen.

Wollen Sie erneut die Aufrufkette zum vorangegangenen Laufzeitfehler sehen,
dann mב¶ssen Sie das ScannerΓêÆSymbol bei festgehaltener ShiftΓêÆTaste anwבñhlen
(z.B. mit Shift−S). Sie sehen dann die oben beschriebene Scanner−Box.

ב£bergeben Sie dagegen eine Datei an den Scanner, indem Sie sie auf das
Symbol schieben, so bekommen Sie die MבÀglichkeit, eine Fehleradresse von
Hand einzugeben. Gemeint ist hier immer die relative Adresse innerhalb des
Moduls, wie sie auch nach Laufzeitfehlern angezeigt wird. Um die Arbeitsdatei
zu scannen, brauchen Sie das Scanner−Symbol nur doppelt anklicken.

Fragt der Scanner nach der relativen Position, ist der vorher beim Laufzeit-
fehler angezeigte Wert einzugeben. Dabei ist zu beachten, daבƒ der Wert, wie
bei der Anzeige, mitsamt dem "$"−Zeichen eingegeben wird, da dies eine
Hexadezimalzahl kennzeichnet.

2.6 Linker

Funktion

In Kapitel 1.4 haben wir schon beschrieben, warum das Megamax Modula−
System eigentlich ohne Linker auskommt: Der Loader als Teil der Entwicklungs-
umgebung sorgt fב¶r automatisches Load Time Linking, wenn Sie aus der Shell
ein Programm starten.

Wollen Sie aber ein ModulaΓêÆProgramm als eigenstבñndige TOSΓêÆ oder PRGΓêÆ
Anwendung verwenden, dann muבƒ es komplett mit allen benutzten Modulen in
einer Codedatei abgelegt werden, damit das TOS damit zurechtkommt.
Auבƒerdem mב¶ssen noch einige zusבñtzliche Anweisungen eingefב¶gt werden, um
fב¶r die Module die gleiche Laufzeitumgebung bereitzustellen, wie sie bei Aufruf
aus der Shell herrscht.

Eine solche Codedatei erzeugt der Linker − erfreulicherweise kann er das
vollautomatisch. Sie ב¶bergeben ihm nur den Namen des Hauptmoduls; der
Linker lבñdt alle importierten Module dazu und fב¶gt zusבñtzlich ein spezielles
InitialisierungsΓêÆModul ein. Das resultierende Programm kann dann vבÀllig
unabhבñngig vom ModulaΓêÆSystem, z.B. unter dem GEMΓêÆDesktop, gestartet
werden; daher kבÀnnen Sie Programme in dieser Form auch an Dritte
weitergeben, die das Megamax Modula−System nicht besitzen (siehe Kapitel
1.5).

Bedienung

Der Linker wird aufgerufen wie alle anderen Systemprogramme: Legen Sie mit
der Maus eine CodeΓêÆDatei auf dem LinkerΓêÆSymbol auf der Arbeitsflבñche ab
(oder klicken Sie das LinkerΓêÆSymbol an, um die Arbeitsdatei zu ב¶bergeben).
Bevor Sie den Linker starten, sollten Sie aber ב¶berprב¶fen, ob folgende Voraus-
setzungen erfב¶llt sind:

* Von allen Modulen, die in das Programm importiert werden, muבƒ das ב¶ber-
setzte Implementationsmodul vorhanden sein. Zusבñtzlich werden evtl. weitere
Module benבÀtigt (siehe folgenden Abschnitt Konfigurationsmodule). Die Imple-
mentationsmodule werden auf den Pfaden der ImpPath−Liste (siehe Kap. 2.2,
Batch−Dateien) gesucht.

* Das fertig gelinkte Programm wird auf dem Pfad gespeichert, der fב¶r das
ב¶bergebene Hauptmodul angegeben wurde. (Sie kבÀnnen hier bewuבƒt einen Pfad
− durch Doppelklick auf das "aktuelle Datei"−Fenster oder Control−P −
angeben, auf dem das Hauptmodul gar nicht zu finden ist, um die Ausgabe zu
lenken; das Hauptmodul wird dann auf allen Pfaden der ModPath−Liste
gesucht). Auf der Zieldiskette muבƒ genב¶gend Platz sein ΓêÆ durch die
zusבñtzlichen Module wird das gelinkte Programm im allgemeinen wesentlich
grבÀבƒer als das ursprב¶ngliche Modul.

Wenn keine Schwierigkeiten auftreten, baut der Linker auf dem Bildschirm eine
Liste der importierten Module auf. Zuerst werden dabei stets die Konfigura-
tions−Module (s.u.) aufgenommen, gefolgt von ihren Importen. Dann folgen das
von Ihnen angegebene Hauptmodul und dessen Importe. Schlieבƒlich meldet der
Linker den erfolgreichen Ablauf und speichert das fertige Programm ab.

Fertig − mehr zu Bedienen gibt's in der Regel nicht! Es sei denn, Sie werden
mit einer der folgenden Fehlermeldungen konfrontiert:

Fehlermeldungen

Alle Meldungen beginnen mit der Angabe, welches Modul das Problem ausgelבÀst
hat und von welchem anderen Modul es benבÀtigt wurde: "Importing
א½FehlerModulא† into א½KundenModulא†". Dann folgt eine Fehlerbeschreibung.
Allgemein gilt: Der Linker interessiert sich immer fב¶r ב¶bersetzte Implemen-
tationsmodule ΓêÆ alle Probleme kבÀnnen sich also nur auf diese Dateien beziehen.

Module not found

Das ב¶bersetzte Implementationsmodul wurde auf keinem der Pfade
gefunden, die in der IMPPATH−Pfadliste in der Shell−Info definiert sind.

Wrong module format

Die geladene Datei ist kein korrekt aufgebautes Implementationsmodul;
vermutlich ist die Datei beschבñdigt.

Error in relocating list

Die Relozierliste (Bestandteil jedes ב¶bersetzten Moduls) ist fehlerhaft;
vermutlich ist die Datei beschבñdigt.

Bad module layout

Das Modul wurde mit einer alten Compilerversion ב¶bersetzt, die ein
anderes Dateiformat erzeugt. Modul neu ב¶bersetzen!

File is damaged

Beim Laden des Moduls ist ein Lesefehler aufgetreten.

Wrong module version

Die gefundene Version des Moduls paבƒt zu einem anderen Definitionsmodul
als beim ב£bersetzen des Kundenmoduls vorlag. (Das Modul exportiert nicht
genau die Bezeichner, die das Kundenmodul erwartet.) Ggf. beide Module
neu ב¶bersetzen!

Out of memory

Der Hauptspeicher reicht nicht aus. Evtl. vorhandene Accessories oder
RAM−Disk entfernen.

Too many modules (list overflow)

Mehr als die in den Parametern eingestellte Anzahl Module sollen gebunden
werden. ErhבÀhen Sie den Wert Max. Module unter Parameter/Linker und
wiederholen Sie den Linker−Aufruf.

Auבƒerdem sind I/O ErrorΓêÆMeldungen mבÀglich. Sie enthalten jeweils eine
Beschreibung des Fehlers und beziehen sich stets auf die Ausgabe−Datei.

Linker−Optionen

Beim Menב¶punkt Parameter
kann unter Linker eine Dia-
logbox geבÀffnet werden, die
das Einstellen aller Optionen
beim Linken zulבñבƒt.

In den acht Treiber−Feldern
werden die Initialisierungs−
und Konfigurations−Module
eingetragen, die weiter unten
ausfב¶hrlich behandelt wer-
den. Die StackgrבÀבƒe wird
ebenfalls spבñter erlבñutert. Der Wert hinter Max. Module bestimmt, wie viele
Module maximal zu linken sein werden. Ist dieser Wert zu klein gewבñhlt,
meldet der Linker einen Fehler und Sie mב¶ssen den Wert erhבÀhen. Er sollte
aber auch nicht unnבÀtig groבƒ gewבñhlt werden, weil je nach seiner GrבÀבƒe mehr
oder weniger Speicherplatz von vornherein vom Linker reserviert wird.
Besonders, wenn mangels Speicher בÀfter die Fehlermeldung Out of memory
beim Linken erscheint, sollten Sie diesen Wert so klein wie mבÀglich halten.

Treiber− bzw. Konfigurations−Module

Zusבñtzlich zu den Modulen, die Sie explizit (durch IMPORTΓêÆAnweisungen) in
Ihren Programmen benutzen, kann der Linker noch weitere Module in die
CodeΓêÆDatei einbinden. Mindestens ein solches Modul wird (fast) immer benבÀtigt,
um vor dem Start des Modula−Programms die Laufzeitumgebung vorzubereiten.
Weitere Module, die mitgeliefert wurden, stellen Ausgabefunktionen auf
unterster Ebene fב¶r TOSΓêÆ oder GEMΓêÆUmgebung bereit.

Das System ist bereits so konfiguriert, daבƒ alle Programme 'gelinkt' werden
kבÀnnen, ohne daבƒ Sie sich um diese zusבñtzlichen Module kב¶mmern mב¶בƒten. Sie
kבÀnnen die Konfiguration dieser Module aber von der Shell aus mit dem
Menב¶punkt Parameter/Linker einstellen. In der Dialogbox (s.o.) existiert eine
Liste fב¶r mit acht Treibern. Vor jeden dieser Treiber kבÀnnen Sie durch
Anklicken ein Hבñkchen setzen oder lבÀschen ΓêÆ nur die so markierten Modul-
namen werden beim Linken eingebunden. Normalerweise sind fב¶nf der acht
mבÀglichen Namen eingetragen:

M2Init sorgt fב¶r die Vorbereitung der Laufzeitumgebung. Dieses Modul muבƒ in
jedem Codefile enthalten sein − bitte nur 'abschalten', wenn es extra verlangt
wird, wie z.B. beim Linken von MoreMem (UTILITY−Ordner) oder wenn Sie
selber die Initialisierung in Ihrem Modul vornehmen wollen.

GEMError ב¶bernimmt die Behandlung von Laufzeitfehlern. Wenn dieses Modul
vorhanden ist, werden Laufzeitfehler in einer Alert−Box mit Fehlerbeschreibung
und −position angezeigt. GEMError kann nur sinnvoll bei keine Optimierung oder
verkב¶rzende Optimierung mit eingelinkt werden. Wird vollstבñndig optimiert, ist
statt dessen SimpleError einzubinden.

SimpleError ist eine einfachere Fehlerbehandlung als GEMError, die, falls ב¶ber-
haupt ein Fehlerabfangen erwב¶nscht ist, bei vollstבñndig optimierten Programmen
gewבñhlt werden muבƒ.

Um Platz zu sparen, kבÀnnen Sie GEMError bzw. SimpleError auch weglassen ΓêÆ
dann erscheinen bei Laufzeitfehlern nur die allseits bekannten BבÀmbchen.

GEMIO enthבñlt Ausgabefunktionen, auf die sich das InOutΓêÆModul stב¶tzt. Diese
Funktionen lenken die Ausgabe auf ein Fenster, wie Sie es vom Arbeiten mit
der Megamax ModulaΓêÆShell kennen. Leider ist die Unterstב¶tzung dieser
'hב¶bschen' Ausgabe recht aufwendig, und die fertige CodeΓêÆDatei wird relativ
lang. Daher kבÀnnen Sie, wenn Ihr Programm sonst keine GEMΓêÆFunktionen
benutzt, ohne Programmבñnderung wahlweise auch TOSΓêÆAusgabe ב¶ber das
TOSIOΓêÆModul wבñhlen:

TOSIO enthבñlt die gleichen Ausgabefunktionen wie GEMIO, allerdings fב¶r
Ausgabe auf dem TOSΓêÆBildschirm (schwarz auf komplett weiבƒem Grund mit
Textcursor, keine GEM−Funktionen, keine Maus). Wenn Sie dieses Modul statt
GEMIO aktivieren, geben alle InOut−Funktionen auf dem TOS−Bildschirm aus.
Damit das GEMΓêÆDesktop die richtigen Initialisierungen beim Starten durchfב¶hrt,
sollte das fertig gebundene Programm von '.PRG' in '.TOS' umbenannt oder von
vornherein das Modul durch die Option $E MOS im Quelltext als TOS−
Programm klassifiziert werden.

Achtung: TOSIO verwendet die BIOS−Funktionen zur Bildschirm−Ein−/Ausgabe
und erlaubt somit keine DateiΓêÆUmleitung (I/OΓêÆRedirection) von auבƒen, z.B. ב¶ber
eine CommandΓêÆShell. Dafב¶r kann solch ein Programm nicht einfach durch
Eingabe von Control−C abgebrochen werden.

GEMDOSIO ist, ebenso wie TOSIO, fב¶r TOSΓêÆ und TTPΓêÆProgramme zustבñndig.
Es erlaubt die Umlenkung von EinΓêÆ/Ausgaben ב¶ber das Modul InOut von
auבƒerhalb (beispielsweise ב¶ber eine CommandΓêÆShell) und den Programm-
abbruch ב¶ber ControlΓêÆC, da die EinΓêÆ/Ausgaben ב¶ber die GEMDOSΓêÆFunktionen
geschehen. Ist Ihnen der Sinn dieser Anwendung nicht klar, verwenden Sie
besser TOSIO!

Nochmal in Kurzform: Benutzen Sie M2Init immer; entweder GEMError oder
SimpleError wenn ordentliche Fehlermeldungen gewב¶nscht sind; entweder
GEMIO, TOSIO oder GEMDOSIO, wenn InOut−Funktionen benutzt werden.
(Falls das Programm InOut gar nicht benutzt, sollten diese IO−Module weg-
gelassen werden, um das Programm nicht unnבÀtig zu vergrבÀבƒern.)

Komprimierung (Optimierung) des zu erzeugenden Programms

Durch die Wahl einer der vier gezeigten
Optionen lבñבƒt sich bestimmen, inwieweit
die zusammengefב¶gten Module im
erzeugten Programm komprimiert
werden sollen.

Die erste Einstellung keine Optimierung fב¶gt die Module ohne Komprimierung
zusammen. Zudem werden die Informationen ב¶ber alle Module mit eingebunden,
die benבÀtigt werden, wenn das Loadtime Linking vom gelinkten Programm
verwendet werden soll. Diese Option ist also zu wבñhlen, wenn ein Programm
erzeugt wird, das den Loader importiert, um andere Module starten zu kבÀnnen,
z.B. bei der Shell dieses Systems (MM2Shell).

Alternativ zu keiner Optimierung kבÀnnen auch nur Prozedurnamen entfernt
werden. Dadurch bleiben die Module vollstבñndig erhalten, nur werden die
Symboltabellen, die die einzelnen Prozedurnamen enthalten, entfernt. Loadtime
Linking ist dann weiterhin mבÀglich, nur ist das Scanning (s. Kap 2.5, Debugger)
und die Anzeige der Prozedurnamen bei Laufzeitfehlern nicht mehr mבÀglich.
Diese Komprimierung ist fב¶r Sie meist nicht von Interesse. Lediglich beim
Linken der Shell (sofern Sie daran בänderungen vorgenommen haben) sollten
Sie sie anstatt keiner Optimierung anwenden, weil Sie dabei ca. 10 KByte
einsparen. Da Sie im Allgemeinen bei Fehlern in den MOS−Modulen keine
Korrekturen vornehmen kבÀnnen, kבÀnnen Sie bei diesen Modulen ja ruhig auf die
MבÀglichkeit zum Scanning verzichten. Auf Module, die per Loadtime Link von
der Shell gestartet werden, hat dies keinen Einfluבƒ.

Die Option Prozedurnamen erhalten erzeugt kompaktere Programme. Dabei
werden alle Funktionen entfernt, auf die es keine Referenz zur Laufzeit gibt.
Das gelinkte Programm enthבñlt demnach nur Module mit Funktionen, die
aufgerufen werden kבÀnnen und Module mit exportierten Variablen, die von den
benבÀtigten Prozeduren benutzt werden. Zusבñtzlich enthalten sind, wie bei den
vorigen Optionen,die Informationen ב¶ber die Module, die fב¶r eine Laufzeitfehler-
analyse (Anzeige der Prozedur− und Modulnamen und der aufrufenden
Prozeduren) mittels des Moduls GEMError benבÀtigt werden. In dieser Form ist
kein LoadΓêÆTimeΓêÆLinking vom gelinkten Programm aus mבÀglich.

Wenn weder vom Loadtime Linking (Starten von Modulen mittels des Loaders),
noch von der komfortablen Fehleranalyse (Import von GEMError) Gebrauch
gemacht werden soll, kann die letzte Einstellung vollstבñndige Optimierung
gewבñhlt werden. Sie erzeugt die kompaktesten Programme, indem im
Unterschied zur vorigen Option die Informationen zur Fehleranalyse weg-
gelassen werden. Damit eventuelle Fehler trotzdem ordentlich angezeigt
werden, muבƒ SimpleError statt GEMError eingebunden werden.

Vorsicht:

Bei der vollstבñndigen Optimierung entfernt der Linker alle Module vollstבñndig,
die zwar importiert werden, aus denen aber keine Prozeduren oder Variablen
wirklich benutzt werden. Das heiבƒt: Importieren Sie ein Modul, das in seinem
Initialisierungscode (KבÀrper) lediglich Variablen anderer Module initialisiert oder
importierte Prozeduren dort aufruft, verschwinden diese Anweisungen!

Dieser Effekt tritt nur beim optimierten Linken auf. Haben Sie also ein
Programm, das ungelinkt unter der Shell oder nicht−optimiert gelinkt fehlerfrei
lבñuft, optimiert gelinkt aber nicht funktioniert, prב¶fen Sie, ob die beschriebene
Situation bei Ihnen vorkommt. Sie kבÀnnen es auch daran erkennen, daבƒ solche
Module beim Linken zwar erst beim Einladen angezeigt werden, dann aber
wieder vom Bildschirm gelבÀscht werden, weil sie vollstבñndig entfernt wurden.

Um dies zu verhindern, mב¶ssen Sie die wegoptimierten Module mit der
Direktive B+ ב¶bersetzen, entweder durch $B+ im Quelltext oder durch ΓêÆB in
der Eingabezeile fב¶r Direktiven in der CompilerΓêÆParameterΓêÆBox.

Zusammenfassend seien pauschal diese Regeln zu befolgen:

* Accessories sollten mבÀglichst kurz sein und dב¶rfen nie mit einem Fehler
abbrechen, da dann das gesamte System nicht mehr funktionsfבñhig ist.
Deshalb ist am besten nach eingehendem Testen das Modul mit der Option
$R− zu compilieren, um Platz zu sparen, und das Programm dann mit
vollstבñndiger Optimierung und ohne Fehlermodule zu linken (also in LinkerΓêÆ
Optionen nur M2Init aktivieren).

* Die Shell MM2Shell wird mit der Einstellung keine Optimierung oder nur
Prozedurnamen entfernen und den Modulen M2Init, GEMIO und GEMError
gebunden. Max. Module sollte den Wert 100 haben. Falls der Linker nicht linken
will, weil der freie Speicher nicht ausreicht, entfernen Sie die resident
geladenen Programme (z.B. Compiler und Editor). Wenn das nicht reicht,
entfernen Sie Ihre Accessories, residente Programme im AUTO−Ordner und
ggf. auch eine vorhandene RAMΓêÆDisk (dann mב¶ssen die Suchpfade ImpPath und
ModPath ggf. die Pfadnamen fב¶r die IMPΓêÆ und MODΓêÆDateien auf den
Laufwerken A: oder B: enthalten, damit die Modulcodes dann von Disk geladen
werden kבÀnnen).

* Sonstige Programme kבÀnnen in der Regel mit der vollstבñndigen Optimierung
gelinkt werden, um zu erreichen, daבƒ die Programme mבÀglichst wenig Platz auf
Disk und im Speicher beim Ausfב¶hren belegen. Zur Sicherheit sollte allerdings
das Modul SimpleError mit eingebunden werden, damit in einem unerwarteten
Fehlerfall das Programm sich nicht gleich mit BבÀmbchen verabschiedet, sondern
statt dessen eine Meldung zeigt, um was fב¶r einen Fehler es sich handelt. Ist
allerdings mit Laufzeitfehlern zu rechnen, ist es sinnvoller, verkב¶rzende
Optimierung zu wבñhlen und GEMError einzubinden. Dann ist bei einem Fehler

* Bei allen normalen Programmen, auch Accessories, muבƒ M2Init als erstes
Treibermodul eingebunden werden, weil dieses Modul dafב¶r sorgt, den
ב¶berflב¶ssigen Speicher freizugeben, die globalen Variablen (das BSS Segment)
zu lבÀschen und die einzelnen Module zu initialisieren (die ModulkבÀrper werden
alle nacheinander aufgerufen).

* Es ist immer darauf zu achten, daבƒ die Module GEMIO, TOSIO oder
GEMDOSIO nur dann eingebunden zu werden brauchen, wenn das Modul InOut
verwendet wird. Ansonsten erzeugt das Einbinden dieser Module nur unnבÀtig
lange Programme.

StackΓêÆGrבÀבƒe

Ebenso wie bei Modulen, die unter der Shell mit Loadtime−Linking gestartet
werden, kann die StackgrבÀבƒe auch fב¶r gelinkte Programme bestimmt werden
(siehe auch Kap. 2.2, Kommandozeile). Ist der Wert Null eingetragen, wird die
StandardΓêÆGrבÀבƒe verwendet, die in M2Init bestimmt ist (normalerweise 8192
Bytes). War beim Starten eines Moduls unter der Shell ein grבÀבƒerer Stack
nבÀtig, so ist dieser in der Regel genauso beim Linken in der LinkerΓêÆParameterΓêÆ
Box einzustellen. Ist der Stack des gelinkten Programms zu klein, wird eine
entsprechende Fehlermeldung wבñhrend des Programmlaufs angezeigt, sofern
GEMError bzw. SimpleError mit eingebunden wurde.

Binden von Accessory−Programmen

ב£brigens: Accessories (Endung ACC) kבÀnnen ohne weiteres mit dem Linker
erzeugt werden, ihre Endung muבƒ nur ggf. auf ACC angepaבƒt werden, wenn
nicht schon im Programmtext mit einer Zeile wie (*$E MAC *) die Endung fב¶r
den Linker vorbereitet wird. Mit Hilfe der Funktion PrgCtrl.Accessory kann das
Programm gar abfragen, ob es nun als normales PRG−Programm oder als
Accessory mit Endung ACC gestartet wurde, und entsprechend reagieren
(Accessories mב¶ssen sich zusבñtzlich in die Menב¶leiste eintragen und dב¶rfen
nicht terminieren!).

Fast Load−, Fast Code− und Fast Memory−Flags

In neueren TOS−Versionen werden drei neue Kennungen im Programmkopf von
gelinkten Programmen ausgewertet. Das Fast Load−Flag (seit TOS 1.4)
bestimmt, ob ein Programm es nבÀtig hat, daבƒ beim Start seine TPA gelבÀscht,
also mit NullΓêÆBytes beschrieben werden soll. Die TPA ist der grבÀבƒte freie
Speicherblock, in dem das Programm selbst auch steht. Sie ist Bestandteil des
Heaps; dem Speicher, der mit dem Storage−Modul angefordert werden kann.
Ist das Flag gesetzt, wird die TPA nicht gelבÀscht. ModulaΓêÆProgramme, die
unter der Shell vom Loader gestartet werden, erhalten den Heap nie gelבÀscht,
so brauchen Sie es in der Regel auch nicht, wenn sie gelinkt gestartet werden.
Daher kann das Fast Load−Flag immer aktiviert bleiben.

Die Flags fב¶r Fast Code und Fast Memory bestimmen bei Atari TTΓêÆRechnern,
ob der "schnelle" Speicher dieses Computers mitbenutzt werden darf.
Einschrבñnkungen gibt es hier nur selten, beispielsweise, wenn Sie die
Videospeicher−Adresse in einen anderen Bereich legen wollen, denn dies darf
nur im "normalen" Speicher der ersten 16 MByte geschehen − das Fast RAM
liegt aber oberhalb der ersten 16 MB.

Fast Code bestimmt, ob der Programmcode im schnellen Speicher ablaufen
darf, Fast Memory, ob bei Speicheranforderungen (vom Heap) auch der
schnelle Speicher vergeben werden darf. Funktioniert ein Programm nicht auf
dem TT, sollten Sie zuerst diese Flags probeweise abschalten.

Arbeitsweise des Linkers

Bekanntermaבƒen wird der Linker dazu verwendet, um aus einem Hauptpro-
gramm und seinen Bibliotheken ein Programm zu erzeugen, das auch auבƒerhalb
der MegamaxΓêÆShell ausfב¶hrbar ist.

Die Mindestanforderung an den Linker ist dabei, das Hauptmodul mit allen
importierten Modulen zusammenzufב¶gen und die Adressen der "externen"
Prozeduren und Variablen zu verketten. Auבƒerdem mב¶ssen die Relozierinfor-
mationen der einzelnen Module vom fב¶r das LoaderΓêÆModul verstבñndlichen
Format in das TOS−Format umgewandelt werden. Dann kann daraus eine Datei
erzeugt werden, in der am Anfang noch Informationen abgelegt werden, wie
lang der Programm− und der Variablenbereich sind und wo im Programmcode
der KבÀrper des Hauptmoduls liegt, also des Teils, in dem mit der Ausfב¶hrung
begonnen werden soll.

Nur reicht das in der Regel nicht aus, denn so wird zwar das Hauptmodul
beim Starten des gelinkten Programms ausgefב¶hrt, aber die ihm untergeordne-
ten Module wurden nicht initialisiert. Es ist notwendig, zusבñtzlich die KבÀrper
der anderen Module vorher auszufב¶hren. Aus diesem Grund legt der Linker

M2Init, dessen KבÀrper als erstes Modul ausgefב¶hrt wird, weil es vom Linker
als Hauptmodul verstanden wird, sorgt auבƒerdem fב¶r richtige Initialisierung des
Programms. Zuerst ermittelt es, ob es als Accessory gestartet wurde; in
diesem Fall fordert es erst einmal Speicher an, um ihn als Stack verwenden
zu kבÀnnen. Im anderen Fall hat es bereits den gesamten freien Speicher als
Stackbereich erhalten und verkleinert ihn deshalb erstmal und gibt den unbe-
nutzten Bereich an das System zurב¶ck.

Der Linker hat dafב¶r gesorgt, daבƒ in dem Adreבƒregister A0 die Adresse der
BaseΓêÆPage und in A1 die Adresse der Liste mit den Verweisen auf die KבÀrper
der anderen Module ב¶bergeben werden. So ruft M2Init dann alle von ihm selbst
importierten ModulkבÀrper auf (sie stehen zu Beginn der Liste, die mit einem
NILΓêÆZeiger abschlieבƒt) und dann eine Prozedur aus dem Modul MOSCtrl, um
ihr die Adresse einer Tabelle mitzuteilen, welche ebenfalls vom Linker erzeugt
wurde, und in welcher, sofern nicht vollstבñndige Optimierung gewבñhlt wurde,
die Informationen ב¶ber alle vorhandenen Module enthalten sind (z.B. Modulname,
Adresse und Lבñnge im Speicher, usw.). Diese Tabelle wird vom Modul ModBase
verwaltet und von ModCtrl und Loader mitverwendet. Sie wird z.B. benבÀtigt,
um bei einer Fehleranzeige durch GEMError den Modulnamen und ggf. den
Prozedurnamen zu ermitteln.

Ist die Initialisierung des MOS−Systems abgeschlossen, werden die restlichen
ModulkבÀrper ausgefב¶hrt (die Liste wird fortgesetzt und wiederum mit NIL
abgeschlossen), wobei der letzte KבÀrper das eigentliche Hauptmodul ist.

Nun ist es theoretisch unnבÀtig, immer die importierten Module vollstבñndig
einzubinden, da normalerweise nicht alle Prozeduren (zumindest bei den mitge-
lieferten Bibliotheksmodulen) verwendet werden. Deshalb gibt es die MבÀglich-
keit, die Programme optimiert zu linken. Beim Megamax Modula−2 gibt es
zwei Stufen der Optimierung. Beide haben gemeinsam, daבƒ alle Prozeduren, die
keinesfalls benבÀtigt werden, vor dem Zusammenbinden aus den Modulen
entfernt werden. Ergibt sich dabei, daבƒ trotz ImportΓêÆAnweisung eines Moduls
aus diesem weder Prozeduren noch Variablen verwendet werden, wird sogar
das gesamte Modul nicht eingebunden (dies ist daran zu erkennen, daבƒ solche
Modulnamen im Fenster nach dem Optimiervorgang wieder verschwinden). Dies
ist u.a. bei Modulen der Fall, die nur Konstanten enthalten (z.B. MOSGlobals).

Soll ein Modul nicht komplett wegoptimiert werden kבÀnnen, obwohl es keine
Funktionen und Variablen exportiert, aber beispielsweise in seinem ModulkבÀrper
Variablen, die es aus anderen Modulen importiert hat, initialisiert oder auch
dort importierte Funktionen aufruft, muבƒ in seinem Quelltext ΓêÆ am besten zu
Beginn ΓêÆ die CompilerΓêÆOption $B+ aufgefב¶hrt werden!

Ob eine Prozedur benבÀtigt wird, erkennt der Linker daran, daבƒ er nachsieht
ΓêÆ ausgehend von jedem ModulkבÀrper ΓêÆ welche Prozeduraufrufe darin vorkom-
men. Diese gefundenen Prozeduren werden nun wiederum selbst alle auf
weitere Aufrufe ב¶berprב¶ft (eine an sich ganz einfache Sache). Es werden dabei
auch Prozeduren ermittelt, die zwar als Aufrufe von aufgerufenen Prozeduren
gefunden werden, jedoch nie ausgefב¶hrt werden, weil eine damit verbundene
Bedingung niemals eintritt − aber dies kann der Linker nicht herausfinden und
optimiert sie deshalb nicht weg.

Alle Prozeduren, die auf diesem Wege nicht gefunden wurden, werden als
nicht benבÀtigt deklariert und somit beim Binden aus den Modulen entfernt.
Lokale Prozeduren werden ב¶brigens immer zusammen mit ihren globalen
Vבñtern behandelt. Es kann nicht erkannt werden, daבƒ lokale Prozeduren nicht
benבÀtigt werden. Es wird nur auf die globalen Rב¶cksicht genommen und die
lokalen mב¶ssen mitziehen (informatisches Machtgefב¶ge). Prozeduren, die auf
dem בñuבƒersten Scope von lokalen Modulen ihren Platz haben, werden natב¶rlich
wie globale Prozeduren behandelt. Bitte erwarten Sie aber nicht, daבƒ die
lokalen ModulkבÀrper auch entfernt werden, wenn das globale Modul keine
Variablen oder Prozeduren aus dem lokalen Modul verwendet!

Die beiden Optimierungsmodi unterscheiden sich nur darin, daבƒ beim
"vollstבñndigen Optimieren" auch die Informationen ב¶ber die Module fב¶r das
Modul ModBase und die Prozedurnamen entfernt werden, wohingegen beim
anderen Modus diese Daten erhalten bleiben, um dem Modul GEMError die
gewohnte Ausfב¶hrlichkeit bei der Anzeige von Laufzeitfehlern zu bieten.

Prinzip eines Make

Das Make ist ein Hilfsprogramm, das nicht unbedingt zur Programmentwicklung
benבÀtigt wird, das aber bei umfangreicheren Programmprojekten sehr hilfreich
ist.

Arbeiten Sie an einem Programm, das aus mehreren Modulen besteht, die
hבñufig geבñndert werden, mב¶ssen Sie ja immer darauf achten, diese בänderungen
vor einem neuen Programmstart zu ב¶bersetzen. Bei gleichzeitigen בänderungen
in mehreren Modulen kann es vorkommen, daבƒ Sie dann ein Modul zu
ב¶bersetzen vergessen. Bei Definitionsבñnderungen erhalten Sie dann meistens
eine Fehlermeldung vom Loader (welchen die Shell dann anzeigt) oder vom
Linker, daבƒ ein Versionskonflikt zwischen den Modulen vorliegt. Im ungב¶n-
stigeren Fall wird nichts bemerkt und beim Start des Programms machen sich
dann die vermeintlichen בänderungen nicht bemerkbar, was zu groבƒer
Verwirrung fב¶hren kann.

In diesem Fבñllen ist es also notwendig, alle betroffenen Module neu zu ב¶ber-
setzen. Weiבƒ man nicht, welche das sind, ist das dann sehr zeitaufwendig. Ein
Make versucht nun, anhand bestimmter Anhaltspunkte selbst herauszufinden,
welche Module nach erfolgten בänderungen neu zu ב¶bersetzen sind. Hierzu gibt
es verschiedene Verfahren. So kבÀnnte beispielsweise der Editor jedes
geבñnderte Modul irgendwie markieren, indem es seinen Namen in eine Datei
schreibt. Dann kבÀnnte das Make diese Module alle compilieren lassen. Da das
Megamax−System aber jeden beliebigen Editor zur Programmentwicklung
zulassen soll, wב¶rde dies Verfahren nicht helfen, weil kein Fremdeditor solch
eine Markierung vornehmen wב¶rde.

Arbeitsweise von Make

Die einzige Markierung, die jeder Editor automatisch nach einer בänderung
vornimmt, liegt darin, daבƒ beim Abspeichern jedes geבñnderten Textes das
Betriebssystem (GEMDOS) die aktuelle Tageszeit und das Datum der Datei mit
im Inhaltsverzeichnis speichert. So kann jedem Text angesehen werden, wann
er zuletzt ΓêÆ wahrscheinlich nach einer בänderung ΓêÆ gespeichert wurde. Da
ebenso die vom Compiler ב¶bersetzten CodeΓêÆDateien beim Abspeichern mit der
aktuellen Zeit vermerkt werden, kann das Make durch Vergleich der Zeiten
von TextΓêÆ und CodeΓêÆDatei entscheiden, welche Datei jב¶nger ist: Ist ein Text
jב¶nger, muבƒ er compiliert werden, wurde er daraufhin ב¶bersetzt, ist der
resultierende Code jב¶nger, woraufhin das Make beim wiederholten Start nun
alles als aktualisiert erkennt.

Darin liegt also das prinzipielle Vorgehen beim Megamax−Make. Voraussetzung
ist selbstverstבñndlich, daבƒ Datum und Zeit immer stimmen, damit ein nach
einer ב£bersetzung verבñnderter Text auch wirklich eine spבñtere Zeit als die
seines Codes erhבñlt. Besitzen Sie einen MegaΓêÆST, brauchen Sie sich keine
Sorgen darum zu machen, weil diese Rechner eine Batterie−gepufferte
Echtzeituhr enthalten, die auch beim Ausschalten des Computers weiterlבñuft
(vorausgesetzt, Sie haben auch eine geladene Batterie eingesetzt). Den
Besitzern von anderen STΓêÆComputern bieten sich mehrere LבÀsungen: Auch fב¶r
diese Rechner gibt es einsteckbare, nichtΓêÆflב¶chtige Echtzeituhren zu kaufen.
Verfב¶gen Sie nicht ב¶ber so einen Zusatz, mב¶ssen Sie die Zeit nach jedem
Rechnerstart (auch beim Druck auf den RESET−Taster) neu stellen. Dazu
kבÀnnen Sie beispielsweise das bei Ihrem Atari mitgelieferte Accessory
CONTROL.ACC verwenden. Ebensogut kבÀnnen Sie auch aus dem UTILITYΓêÆ Ordner das Programm Timer (Dateiname: TIMER.M) compilieren, linken und als
Accessory mit der Endung ACC auf ihre Boot−Disk kopieren.

Am komfortabelsten fב¶r Anwender ohne Echtzeituhr ist es, das Programm
SetTime aus dem UTILITYΓêÆOrdner zu verwenden: Es muבƒ ב¶bersetzt und gelinkt
und dann in den AUTO−Ordner kopiert werden. Schalten Sie den Rechner neu
ein, erkennt das Programm, daבƒ noch keine gב¶ltige Zeit eingestellt ist und
fordert Sie dazu auf. Wenn Sie dann spבñter den Rechner neu booten, ohne ihn
auszuschalten (z.B. durch Druck auf den RESETΓêÆTaster), ב¶bertrבñgt das
Programm die im Tastatur−Chip des Atari gespeicherte Zeit (die erst beim
Ausschalten des Atari verloren geht) automatisch an das GEMDOS, welches
fב¶r die Zeit der Dateien zustבñndig ist, eine erneute Eingabe bleibt Ihnen damit
erspart.

Das Verfahren des Zeitvergleichs bei den Dateien ist allerdings nicht optimal:
Es kann ja auch vorkommen, daבƒ in einem Modultext nur בänderungen an der
Dokumentation vorgenommen werden, so daבƒ keine Neuב¶bersetzung notwendig
wבñre. Das ist eben ein kleiner Seiteneffekt, der wohl auch von Ihnen akzeptiert
werden kann, oder? Nebenbei: Achten Sie auf die Dokumentationen zu den
mitgelieferten Editoren. So bietet Ihnen beispielsweise der Gepard−Editor die
MבÀglichkeit, den Text mit "K" zu speichern. Dann wird die vorige Zeit der
Datei beibehalten, so daבƒ Make nicht darauf anspricht.

Nun ist das Problem der Markierung von בänderungen an den Modulen gelבÀst.
Aber es gibt noch ein weiteres: בändern Sie ein Definitionsmodul, das von
weiteren Modulen importiert wird, an denen Sie aber keine בänderungen
vornehmen, mב¶ssen diese trotzdem ב¶bersetzt werden. Damit das Make dies
erkennen kann, muבƒ es ב¶ber die augenblicklichen ImportΓêÆVerhבñltnisse der
beteiligten Module informiert sein. Es bietet sich an, ausgehend vom Haupt-
modul des Programms, alle importierten Module zu beschreiben, wiederum mit
deren Importen usw. Diese Beschreibung erfolgt in einer Datei, die dann vom
Make ausgewertet wird:

Das Make sieht sich zuerst die Definitionstexte in der Reihenfolge an, in der
sie importiert werden: Die Module, die selbst keine mehr importieren zuerst,
die, die von keinem anderen importiert werden zuletzt. Ist dabei ein Text
jב¶nger als sein Code, oder existiert der Code gar noch nicht, wird es zur
ב£bersetzung markiert. Alle Definitionen, die ein markiertes Modul importieren,
werden ebenfalls markiert. Dann wird ebenso bei den Implementationen
verfahren: Ist die eigene Definition oder die eines Imports markiert oder ist
der Text jב¶nger als der Code, bzw. fehlt der Code, wird es auch markiert.
Zuletzt werden alle markierten Module in eine Textdatei geschrieben und das
Make sorgt dafב¶r, daבƒ die Module vom Compiler ב¶bersetzt werden.

Erstellung einer Make−Datei (ModRef)

In der Make−Datei wird das Hauptmodul mitsamt aller importierter Module
beschrieben. Um solch eine Datei zu erzeugen, kann das Programm ModRef
verwendet werden. Am besten melden Sie ModRef als Tool an (siehe Kap. 2.2,
Batch−Dateien).

Wird ModRef ausgefב¶hrt, zeigt es den GEMΓêÆDateiΓêÆSelektor, mit dem dann ein
Hauptmodul (ב¶blicherweise Dateien mit der Endung "M") ausgewבñhlt werden
kann. Dann liest das Programm den Quelltext ein und registiert all seine
Importe. Danach werden all die importierten Module gesucht, und zwar sowohl
die CodeΓêÆDateien von Definition und Implementation als auch die zugehבÀrigen
Quelltexte. Dabei werden Module ignoriert, deren Definitions−Codes in der
unter den Compiler−Parametern eingetragenen Bibliotheks−Datei enthalten sind.
Das hat den Effekt, daבƒ solche Module dann nicht mehr vom Make geprב¶ft zu
werden brauchen, was bei den in der Bibliothek enthaltenen Megamax−Modulen
auch nicht mehr nבÀtig ist, da ihre Codes sowohl vorhanden sind als auch
normalerweise nicht verבñndert werden.

Werden Texte von Modulen nicht gefunden, werden sie auch nicht in der
MakeΓêÆDatei berב¶cksichtigt, zur Sicherheit erfolgt aber ein Hinweis vom
ModRef, daבƒ es bestimmte Dateien nicht finden konnte. Wenn Sie vor dem
Start von ModRef nur bestimmte Verzeichnisse als Suchpfade fב¶r die
Quelltexte eintragen (z.B. mit Hilfe von PathEdit), kבÀnnen Sie bequem Modul-
sammlungen fב¶r verschiedene Projekte auseinander halten.

Sind alle Importe festgestellt, erscheint der Datei−Selektor von Neuem.
Normalerweise ist nun Abbruch zu wבñhlen, woraufhin eine MakeΓêÆDatei erzeugt
wird, die den Namen des Hauptmoduls trבñgt, jedoch mit der Endung M2M. Die
Datei wird im selben Verzeichnis abgelegt in der auch der Quelltext des
Hauptmoduls steht. Statt des Abbruchs kann auch ein weiteres Modul
angewבñhlt werden. Dann wird dieses Modul samt seiner Importe ebenfalls in
die MakeΓêÆDatei aufgenommen. Damit wird erreicht, daבƒ bei einem Make auch
zusבñtzliche zum Projekt gehבÀrende Module gemaked werden kבÀnnen.

Wollen Sie gar alle Module aus einem Verzeichnis in die Make−Datei
aufnehmen, kבÀnnen Sie den Modulnamen mit Wildcards eingeben, also
beispielsweise *.M fב¶r alle Hauptmodule des Verzeichnisses.

Muבƒ hבñufig die selbe MakeΓêÆDatei neu erzeugt werden (s.u.), kann dies ב¶ber
einen Batch vereinfacht werden: Schreiben Sie einen Batch, der die folgende
Zeile enthבñlt:

ModRef א½Quelltextnamenא†

Melden Sie diese Textdatei (mit Endung M2B!) am besten als Tool an. Wird
dieser Batch ausgefב¶hrt, wird nicht mehr mit dem DateiΓêÆSelektor nach dem
Quelltextnamen gefragt, sondern der angegebene verwendet. Es kבÀnnen auch
mehrere Textnamen hintereinander aufgefב¶hrt werden, um dasselbe zu
erreichen, wie durch die wiederholte Auswahl mit dem Datei−Selektor.

Es ist darauf zu achten, daבƒ bei jeder בänderung der ImportΓêÆStrukturen der
beteiligten Module die Make−Datei neu erzeugt wird! Wird dies vergessen,
arbeitet das Make zwar meist einwandfrei, trotzdem zeigen sich beim Start
des Programms oft Fehler, wie beispielsweise Versionskonflikte.

Anwendung von Make

Das MakeΓêÆProgramm heiבƒt MM2Make und wird in den ShellΓêÆParametern
eingetragen. Der Aufruf erfolgt, indem eine Make−Datei (Endung M2M) zur
Ausfב¶hrung gebracht wird, indem sie also beispielsweise aus einem Fenster auf
das Ausfב¶hrenΓêÆSymbol gezogen wird. Selbstverstבñndlich kבÀnnen MakeΓêÆDateien
auch als Tool angemeldet sein.

Einen Sonderstatus genieבƒt die MakeΓêÆDatei, die als DefaultΓêÆMake eingetragen
ist (unter Info/Umgebung). Sie kann jederzeit durch die Taste M in der Shell
oder durch eine Sonderfunktion beim Verlassen der Editoren (siehe Kapitel 2.3)
aktiviert werden.

Bei der Aktivierung des Make wird zuerst die betroffene Make−Datei
eingelesen, dann werden, wie oben beschrieben, die Datumseintrבñge der
Dateien geprב¶ft. Am Ende wird eine Datei, die alle zu ב¶bersetzenden Texte
auffב¶hrt, unter dem Namen MAKE.M2C im temporבñren Pfad (einzustellen in
den ShellΓêÆParametern) abspeichert. Sind keine Dateien zu ב¶bersetzen, liefert
MM2Make den ExitCode Eins, sonst Null. Daran erkennt die Shell dann, ob sie
daraufhin den Compiler aufrufen soll. Der ב¶bersetzt dann die geforderten
Module alle auf einmal.

Zeigt das Make also den Fehler Ausgabedatei konnte nicht angelegt werden an,
liegt es meistens daran, daבƒ der temporבñre Pfad nicht auf ein vorhandenes,
beschreibbares Verzeichnis zeigt.

StבÀבƒt der Compiler beim ב£bersetzen auf einen Fehler, wird der Editor
gestartet, um ihn wie gewohnt anzuzeigen. Ist der Fehler korrigiert, kann das
Make fortgesetzt werden, indem der Editor mit dem Kommando zum Make
verlassen wird. In diesem Fall wird nicht das Default−Make sondern die aktive
Make−Datei wieder verwendet, mit der ein erneuter Make−Aufruf stattfindet.

Wird der Editor nach einem Fehler nicht mit dem Make−Kommando verlassen,
erinnert die Shell daran, daבƒ der MakeΓêÆVorgang noch nicht abgeschlossen ist,
und bietet Ihnen an, diesen fortzufב¶hren oder abzubrechen.

Sind syntaktische Fehler in der MakeΓêÆDatei vorhanden, oder kבÀnnen benבÀtigte
Dateien nicht gefunden werden, wird das Make abgebrochen und entweder die
Fehler auf dem Bildschirm angezeigt oder der Editor geladen, um dort den
Fehler in der Make−Datei anzuzeigen.

Alle Module unbedingt ב¶bersetzen (Build )

Wollen Sie alle Module einer MakeΓêÆDatei unabhבñngig von ihrem Datum ב¶ber-
setzen, kבÀnnen Sie dies dem MakeΓêÆProgramm durch ב£bergabe der Option "ΓêÆB"
mitteilen. Entweder starten Sie das Make−Programm manuell (im Batch oder
durch Doppelklick) und ב¶bergeben in der Argumentzeile den MakeΓêÆDateinamen
zusammen mit −B oder Sie tragen −B hinter dem Namen der Make−Datei in
den Umgebungsinformationen ein. Das hat sogar den Vorteil, daבƒ das "ΓêÆB"
nach dem Make wieder daraus entfernt wird − denn einmal reicht's ja wohl.

Fehlermeldungen des Make

Zu wenig Speicher.

Abhilfe: Residente Module/Programme entfernen.

Make−Datei ist leer.

Die eingelesene MakeΓêÆDatei enthבñlt keine Daten

... hat ungב¶ltiges Datum.

Die Zeit der angezeigten Datei liegt hinter der aktuellen Zeit.

Dateifehler: ...

Fehler beim Einlesen oder Anlegen der Datei.

Modul ist doppelt deklariert.

Jedes Modul darf nur einmal in der Make−Datei deklatiert werden.

... wurde nicht oder unvollstבñndig deklariert.

Das Modul ist bei IMPORT angebeben aber nicht deklariert.

Datei(en) nicht gefunden.

Die Datei(en) sind nicht auf den entspr. Suchpfaden zu finden.

Ausgabedatei konnte nicht angelegt werden. (Stimmt "Temp.Pfad"?)

Wahrscheinlich ist der Temp. Pfad in den ShellΓêÆParametern ungב¶ltig.

Syntaxfehler.

Wahrscheinlich wurde zuvor ein Semikolon bei einer Modulliste vergessen.

Syntax der Make−Dateien

moduldefinition =

א½modulnameא† ( ΓêÆIGNORE | codedefinition )

codedefinition =

( ΓêÆMOD | ΓêÆIMP | ΓêÆDEF ) א½dateinameא†

{ −MAIN }

( −NOSRC | sourcedefinition )

sourcedefinition =

ΓêÆSOURCE א½dateinameא†

{ ΓêÆINC א½dateiliste) }

{ ΓêÆUSES א½dateiliste) }

{ ΓêÆIMPORT א½modulliste) }

dateiliste =

{ dateiname } ";"

modulliste =

{ modulname } ";"

Jedes in der Modulliste (nach ΓêÆIMPORT) vorkommende Modul muבƒ definiert
sein! Wird es mit −IGNORE definiert, wird es vom Make ignoriert. Mit −INC
kבÀnnen Dateien bestimmt werden, die mittels der IncludeΓêÆDirektive mit in den
Modulsource eingebettet sind. Mit ΓêÆUSES kבÀnnen weitere abhבñngige Dateien,
z.B. ResourceΓêÆDateien, aufgefב¶hrt werden. ΓêÆNOSRC besagt, daבƒ der Quelltext
zu diesem Code vom Make nicht berב¶cksichtigt werden soll. Die Kennung
−MAIN sollte nur bei einem Modul auftauchen. Damit wird das Hauptmodul
markiert, das nach einem erfolgreichen MakeΓêÆProzeבƒ ggf. gestartet werden
kann.